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ABSTRACT 


A timeshared  mi c rocomout er  monitor  for  Intel  ttObO 
microprocessor  systems  development  has  been  described. 
Runninq  on  the  Sycor  ildO  Clustered  Terminal  Processina 
System*  the  monitor  provides  a virtual  environment  composed 
of  a console  device*  eiqht  f Iodpv  disk  drives*  and  an  8n80 
microorocessor  for  uo  to  four  concurrent  users.  Virtual 
floppy  disk  files  on  a five  meqabvte  movable-head  disk 
provide  the  system’s  primary  auxiliary  storaoe  medium. 
Three  different  levels  of  access  protection  are  available 
for  these  virtual  floppy  disk  imaqes.  A commana  1 anouaqe 
processor  has  been  included  to  support  on-line  modification 
of  the  virtual  environment.  System  recovery  in  the  event  of 
a hardware  or  software  failure  is  also  supported  by  the 
mon i tor. 
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INTRODUCTION 


-'pr  — — — ■ " '■ n 


A.  BACKGROUND 

In  the  sumner  of  1976  the  Computer  Science  Department  at 
the  Naval  Postgraduate  School  (NPS)  acquired  a Sycor  Model 
900  Clustered  Terminal  processinq  System  for  use  in  the  HP'S 
microcomputer  laboratory.  The  Sycor  990  utilizes  an  Intel 
8080  LSI  chip  as  the  CPU  of  a special  purpose  microcomputer 
system  designed  primarily  for  data  entrv  applications.  In 
addition  to  the  8080  CPU,  the  990  hardware  configuration 
includes  a five  meoabyte  movable-head  disk,  6 9 K of  random 
access  memory  (RAM),  a cassette  tape  drive,  ana  four  di^olav 
terminals  consisting  of  a keyboard  ana  cathode  ray  tuce 
(CRT)  display  device.  Two  peripheral  devices  are  a'  so 
provided:  a serial  printer  and  an  RS-23?  compatible 
asyncronous  communication  interface. 

As  part  of  the  Model  990  System,  Sycor,  Inc.  supplied  a 
comprehensive  package  of  system  software.  Most  of  this 
software  was  designed  to  support  applications  in  the  data 
entry  field  which  comprised  the  Sycor  990's  primary 
marketing  tarqet.  In  addition  to  the  basic  data  entrv 
packaae  Sycor  also  supplied  several  programs  which  exercise 
the  990's  capabilities  more  fully.  These  includeo  a 
resident  COBOL  compiler*  a cross-compiler  for  PLMR,  a 
relocatable  version  of  the  system  development  1 anouaae  PL/M; 
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and  a linkinq  loader  which  combines  relocatable  segments  of 
COBOL  or  PLMR  object  code  into  an  executable*  oDiect  module. 


Prior  to  the  arrival  of  the  Svcor  4 a 0 , the  facilities 
available  in  the  NPS  m i c rocomnut e r laboratory  consisted 
primarily  of  two  TNTELLEC  8/^00  80  microcomputer  systems 
designed  for  use  in  the  development  of  software*  for.tne 
Intel  8080  chip  processors.  Roth  of  these  systems  support 
the  CP/M  (Control  Program  for  Mi c rocomout e r s ) operatina 
system  [21.  CP/M  provides  many  software  development  tools 
including  a context  editor,  dynamic  debuager,  and  assembler 
for  the  generation  of  8080  object  code  f3-bl.  however,  CP/V 
provides  only  a single  display  terminal  interface,  ana  uses 
floppy  disks  as  its  auxiliary  storaae  medium. 

while  the  Svcor  4 R 0 made  a siani ticant  and  welcome 
addition  to  the  hardware  complement  of  the  NFS  microcomputer 
laboratory,  a great  deal  of  effort  was  reaui red  to  intearate 
the  new  system  into  the  current  laboratory  configuration  and 
to  ensure  that  maximum  benefit  could  be  derived  from  the  new 
acquisition.  The  following  paragraphs  summarize  the  ooals 
and  objectives  of  this  effort. 


the  tutorial  and  research  activities  of  the  MPS 
microcomputer  laboratory.  It  was  felt  that  the  Sycor  440 
hardware  had  the  caoability  to  support  numerous  applications 
more  generalized  than  the  data  entry  function  it  was 
designed  and  programmed  to  accomplish.  In  particular,  the 
cluster  of  four  terminals  suaoested  the  aevelopment  of  a 
timeshared  environment  to  support  uo  to  four  simultaneous 
users  on  a single  Sycor  440.  Such  a timeshared  system  v; o u 1 d 
provide  an  effective  increase  from  two  to  six  6080  CPU’s 
available  for  use  in  the  microcomputer  laboratory.  This 
increase  would  ao  a Iona  wav  towards  meetina  the  increased 
demand  for  microcomputer  research  and  development 
facilitites  at  tips. 

A secondary  goal  of  the  440  integration  effort  was  to 
ensure  that  a well-defined,  compatible  irterface  was 
established  between  the  current  laooratorv  c on f i ou r a t i on  and 
the  newly  acquired  Sycor  system.  The  objective  here  was 
twofold:  first,  to  achieve  hardware  compatibility  between 
the  Sycor  440  and  other  computer  systems  availaple  in  tha 
lab,  and  secondly  to  achieve  software  compatibility  between 
the  Sycor  440  and  other  systems  which  utilize  the  8060  CPU 
chip. 

Achieving  hardware  compatibility  depended  on  tailorino 
the  440's  asyncronous  communication  interface  to  th» 
requirements  of  existina  systems,  particularly  the  POP- 11/50 
which  served  as  the  central  interface  point  for  inter- 
processor communication.  It  was  anticipated  that  this 
hardware  interface  could  be  easily  estaDlished  without 


modification  of  the  Sycor  system. 

Achieving  software  compatibility  was  viewed  as  a much 
more  difficult  objective.  This  would  involve  developing  an 
environment  which  could  SUDoort  software  that  had  already 
been  written  for  other  systems  utilizing  the  8080  CPU  chip. 
For  proarams  developed  at  NPS  this  meant  that  the  Svcor  440 
environment  must  support  a suitably  modified  version  of 
CP/M. 

C.  PROBLEM  DFF  T N T T TOfo 

The  thesis  project  which  eventually  evolved  from.  the 
Svcor  440  integration  effort  was  development  of  the 

Microcomputer  Timeshared  System  (WTS),  a software  monitor 
for  the  Svcor  440  designed  to  support  microcomputer  svstem 
development.  The  possibility  of  orovioina  a virtual  machine 
environment  was  invest iaatedi  including  the  incoroorat ion  of 
virtual  device  interfaces  where  practical.  The  Svcor  4 u 0 
file  svstem  was  to  be  utilized  where  possible  in  order  to 
reduce  develooment  time*  avoid  duolication  of  svstem 
facilities*  and  allow  the  Svcor  operating  svstem  to  be  used. 
The  man-machine  interface  at  the  terminals  was  to  be  simple* 
flexible*  convenient  and  incorporate  the  best  features  of 
existinq  interactive  systems  at  NPS . This  system  was  to 
provide  a suitable  interface  for  user  programs  ano/on 
ooerating  systems  to  enable  utilization  of  the  Svcor  440 
storage  and  peripheral  devices  by  these  proarams. 

It  was  realized  from  the  project's  inception  that  a 
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microcomputer  timesharina  system  is  ideally  implemented 
through  multiprocessing  rather  than  multiorogrammino.  The 
use  of  LST  technoloav  has  made  the  CPU  cost  only  a minor 
factor  in  the  total  cost  of  a microcomputer  system.  A major 
objective  in  the  develoDment  of  MTS  was  finding  an 
efficient#  practical  method  of  sharing  hardware  resources 
other  than  the  CPU.  The  unit  costs  of  memory#  fixed  disks# 
printers#  terminals#  and  other  peripherals  are  major  factors 
in  total  system  cost  - the  sharino  of  these  resources  was 
the  primary  cons i derat i on  . 

To  achieve  the  project  objectives#  a survey  of 
timesharing  concepts  and  implementations  was  conducted. 
Particular  attention  was  devoted  to  the  current  desian  and 
implementation  techniques  of  virtual  machine  timesharina 
svstems  to  determine  those  features  which  could  be  included 
in  MTS.  This  research  included  study  of  timesharing  system 
techniques  associated  with  processor  manaoement#  memory 


II.  TIMESHARING  CONCEPTS 


The  conceDt  of  t i meshari nq  computer  svstew  resources  was 
first  demonstrated  in  the  early  1960's.  Since  that  time, 
growth  in  the  application  of  timesharinq  concepts  to  many 
classes  of  system  operational  requirements  and  desiqns  has 
occurred  raDidlv.  The  timesharino  field  has  matured  now  to 
the  ooint  that  one  can  recoqnize  many  common  design  no a Is 
and  implementation  concepts  beinq  used  in  a wide  variety  o* 
systems.  General  characteristics  of  timesharing  systems, 
methods  of  implementation,  and  resource  management 
techniques  Mere  researched  in  order  to  ioentify  concents 
which  could  be  applied  to  a microcomputer  timeshared  system. 


A.  CHARACTERISTICS  OF  TIMESHARING  SYSTEMS 


One  of  the  original  motivations  for  development  of  early 
timesharing  systems  was  to  obtain  more  efficient  use  o T a 
computer  system's  expensive  operating  time  and  resources 
than  was  beino  realized  through  batch  environments. 
Interactive  or  conversational  timesharing  imposes  the 
additional  burden  of  Weeping  the  "user"  busy,  as  well  as  ’•he 
hardware.  System  response  time  must  be  directly 
proportional  to  the  user's  expectations.  Those  tasKs  which 
the  user  perceives  as  simple  must  result  in  ranid  response 
from  the  system.  For  example,  character  echoing  or  input 


line  editinq  mioht  be  expected  to  require  no  aporeciabl 


delay.  On  the  other  hand,  the  user  would  expect  a 1 arqp 
prooram  assembly  or  compilation  to  take  more  time  and 
therefore  some  delay  would  be  acceptable. 

Another  important  consideration  is  that  of  system 
protection.  The  independence  of  concurrently  execution 
processes  must  be  maintained.  Protection  of  the  system,  from 
user  processes.  as  well  as  user  processes  from  eaen  other, 
must  be  considered.  Protection  of  system  resources  such  as 
the  file  system  and  I/O  devices  must  be  maintained.  Svste” 
protection  may  be  implemented  at  many  levels.  both  in 
hardware  and  software.  within  the  software  system, 
protection  information  for  specific  resources  is  normally 
maintained  in  various  tables  associated  with  these  resources 
1161.  Hardware  mechanisms  can  be  provided  to  support  svstem 
protection.  For  example,  the  use  of  bound  reoisters  to  trap 
invalid  memory  references  could  be  implemented  I10J.  The 
operating  system  can  he  insulated  from  the  user  processes  by 
providing  separate  system  states  (e.g.  system  and  user)  or 
other  lockout  mechanisms  to  identify  when  the  system  is 
executing  in  the  system  rather  than  the  user  state. 

Related  to  system  protection  are  the  important  concerts 
of  system  reliability  and  recove r ab i 1 i t y . The  user  exnects 
the  svstem  to  operate  reliably  and  if  a failure  should 
occur,  to  recover  as  smoothly  and  rapidly  as  possible.  That 
is,  recovery  should  preserve  the  user  data  and  proorams 
which  were  not  related  to  the  failure.  The  goal  in 
desiqninq  recovery  procedures  is  to  minimize  the  impact  of 
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the  recovery  mechanism  on  the  system  when  it  is  operating 


normally*  yet  ensure  smooth  and  rapid  recovery  should  a 
failure  occur. 

B.  VIRTUAL  MACHINES 

In  recent  years*  the  multiplexing  of  computer  system 
resources  has  been  accomplished  in  some  implementations  bv 
utilizing  the  Virtual  Machine  Monitor  (VMM)  concent.  A VMM 
is  a special  form  of  operating  svstem  that  multiplexes  only 
the  physical  resources  amona  the  users  - no  other  functional 
enhancements  are  provided  1101.  The  concept  is  to  nroauc*1 
the  effect  of  multiple  bare  machines  which  are  identical  to 
the  bare  machine  on  whioh  the  VMM  runs.  Thus,  each  user  ca* 
select  the  ooeratina  system  of  his  choice  to  run  on  his 
"private"  computer. 

1.  Virtual  Devices 

Under  the  VMM  concept,  all  I/D  is  simulated.  *\hen  a 
user  program  attempts  to  execute  an  I/O  instruction,  control 
is  t ranferred  to  the  VMM  via  an  interrupt.  There  are 
normally  three  different  situations  which  may  arise: 


(1)  If  the  I/O  device  physically  exists  and  has  been 
assigned  to  that  user  program,  the  instruction  may  be 
executed  immediately  without  modification. 


(.2)  If  a similar 

T/0  device  exists, 

the  I/O  commands 

are 

aopr oo  r i a t e 1 y 

modi f i ed 

and 

then  executed. 

For 

e x amp  1 e , many 

smal 1 disks 

may  be 

simulated  by 

us  i no 

separate  areas  of  a sinole  larqe  disk. 

L 
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(3)  Certain  devices*  such  as  orinters  and  card  readers* 
may  be  extensively  simulated  using  techniques  such  as 
snool i no  (see  Device  Management)  (10). 

2.  Hardware  Requirements 

The  implementation  of  a Dractical  virtual  machine 
monitor  requires  that  the  host  computer  have  certain 
hardware  characteristics: 

(1)  The  instruction  set  should  contain  b o f h privileged  and 
non-prjvi leoed  instructions. 

(?)  The  host  computer  must  have  some  wav  of  di st i nqui sh i nn 
between  the  two  tvces  of  instructions.  That  is*  the 
VMM  must  be  made  aware  of  any  attemot  by  a user's 
proaram  to  execute  a orivileaeo  instruction*  or  cKange 
its  mode  of  ooeration.  This  is  normally  satisfied  bv 
establishing  two  seoarat*  states  of  operation,  system 
and  user. 

(3)  The  VMM  must  be  protected  from  the  user  proarams*  i.e. 
the  memory  assianed  to  the  VWM  must  be  protected  in 
both  read  and  write  mode. 

(4)  The  user  programs  must  be  protected  or  isolated  from 
each  other.  This  means  that  memory  or  input/outDut 
devices  assianed  to  one  user  nroqram  must  be 
inaccessible  from  any  other  user  proaram,  unless 
prooer  safeguards  are  provided.  Isolation  and 
protection  of  memory  areas  can  be  accomplished  by  some 
form  of  memory  protection  or  an  address  translation 
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scheme  (11) 


A machine  which  satisfies  these  requirements  can  ensure  the 
deqree  of  control  by  the  VMM  necessary  to  avoid  excessive 
overhead  in  the  translation  or  simulation  process. 

C.  PROCESSOR  MANAGEMENT 

The  task  of  processor  management  in  the  mu  1 1 i programm i no 
environment  of  a timeshared  system  involves  the  scheduling 
and  managina  of  multiple  processes  in  different  stages  of 
completion.  A process  may  exist  in  one  of  three  states: 
(1)  running,  (2)  ready  to  execute,  or  (3)  blocked  rending 
the  completion  of  I/O  or  some  other  process. 

A process  is  in  the  runninq  state  if  it  is  executing 
instructions.  The  ready  to  execute  (ready)  state  describes 
a process  that  is  ready  tor  execution  but  not  currentlv 
running  due  to  the  unavailability  of  the  CPU.  A blocked 
process  is  one  which  cannot  run  until  some  signal  arrives  to 
unblock  it.  These  unblockina  siqnals  are  referred  to  as 
"wake-up"  signals  and  chanqe  the  status  of  a process  from 
blocked  to  the  ready  state.  Such  signals  can  come  from  many 
sources:  system  processes,  user  processes,  hardware 
interrupts,  such  as  terminal  communications  equipment,  a 
timer,  or  completion  of  a disk  I/O  operation  lift]. 

Since  there  is  no  guarantee  that  a process  will  block 
itself,  timesharing  systems  must  provide  a mechanism  tor 
regaining  control  of  the  CPU  from  the  currently  running 
process  in  order  to  provide  all  users  with  adequate  response 


times 


The  lenoth  of  time  which  a process  is  allowed  to  run 


before  it  is  blocked  is  called  a quantum  or  a timeslire. 
The  auantum  size  is  one  of  the  most’  important  parameters  of 
a schedulina  algorithm.  Tt  mav  be  fixed  or  variable? 
depending  on  other  parameters  such  as  process  size?  process 
priority?  or  length  of  time  the  process  last  ran.  Settinq 
quantum  lenqths  is  a function  of  the  system  characteristics 
and  workload?  and  can  be  determined  only  by  experiment  with 
the  actual  system  or  by  simulation  [161. 

D.  MEMORY  MANAGEMENT 

Memory  manaoement  involves  the  memory  allocation  and 
swaopinq  functions.  This  includes  keepina  t r a c k of  th» 
virtual  memory  space  of  each  process  in  the  svstem,  whether 


it  is  in 

main 

memory  ? 

auxiliary  storaae? 

or  both.  The 

c omo 1 e x i t y 

o f 

this  task 

may  ranqe 

from 

maintainina 

relatively 

few 

tables 

i n 

support  of  a 

single  continuous 

a 1 location 

scheme?  to 

the 

maintaining 

o f 

wany  merrorv 

allocation 

data 

st  ructures 

to  support 

a 

v i r t u a 1 rrerro  r y 

i mp 1 emen t a t i on  using  demand-pao i na  or  segmented  memory 
management  schemes  fl0,t6l. 

Swaopinq  can  be  defined  as  movinq  processes  between  main 
memory  and  auxiliary  storaae  in  order  to  multiplex  main 
memory.  Swapping  time  is  the  time  it  takes  to  complete  a 
swaopinq  task.  The  mu  1 t i p roar amm i nq  of  processes  in  a 
timeshared  system  results  in  the  swaoninq  time  having  a 
major  impact  on  the  system's  response  time.  There  are  two 
important  parameters  of  an  auxiliary  storage  device  that 


1R 


affect  swaoDing  times 


(1)  The  average  lenqth  of  time  required  to  access  the 
required  block  of  information.  This  is  called  the 
average  access  time. 

(2)  The  time  required  to  transfer  the  block  to  and  from 
main  memory.  This  is  inversely  proportional  to  the 
t ransfer  rate  1 1 61  . 

Early  timesharinq  systems  such  as  the  Compatible 
TimeSharinq  System  (CT3S)  used  very  simple  allocation  and 
swaopinq  strateqies  (101.  No  attempt  was  made  to  overlap 
the  execution  of  one  process  with  the  swappino  of  another. 
Only  one  complete  process  resided  in  memory  at  once  ana  all 
processes  were  loaded  relative  to  a constant  fixed  location. 
That  is#  no  dynamic  relocation  was  used  because  no  dynamic 
relocation  hardware  was  available  on  these  early  systems. 

E.  DEVICE  MANAGEMENT 

■ 

Device  management  involves  keepinq  track  of  the  aevic® 
resources/  allocatino  the  device  resources  to  a process# 
initiatino  the  T/0  operation  and  reclaiminq  the  resource  fin 
most  cases  the  I/O  terminates  automatically).  Devices  fall 
into  two  qeneral  cateqories: 

Cl)  Dedicated  - those  devices  which  are  most  efficiently 
assiqned  to  one  user  for  a aiven  time  period#  even 
thouqh  the  user  may  not  be  able  to  utilize  the  aevice 
continuously.  In  this  category  are  tape  drives, 
printers#  and  card  equipment. 
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(2)  Sharable  - those  devices  which,  while  allowing  access 
to  only  one  crocess  at  a time,  can  rapidly  complete 
their  service  tor  individual  orocesses  and  be  auicHv 
switched  to  service  reauests  of  other  processes.  In 
this  cateqory  are  such  online  auxiliary  storage  units 
as  drums,  disks,  and  data  cells  llbl. 

The  operation  o*  so^e  dedicated  devices  may  be  simulated 
to  provide  more  flexibility  and  improved  responsiveness  to 
user  reauests.  For  example,  the  operation  of  printing  a file 
on  the  printer  could  be  transformed  into  a "wrive"  onto  a 
disk  (a  virtual  printer)  where  at  some  later  time  a second 
routine  would  cooy  the  information  onto  the  actual  printer. 
This  process  is  called  sooolina,  and  allows  (1)  dedicated 
devices  to  be  shared,  hence,  more  flexibility  in  scheduling 
these  devices?  (2)  more  flexibility  in  job  scheduling;  and 
(3)  improved  synchronization  of  the  soeed  of  the  device  and 
the  arrival  rate  of  requests  for  that  device  flOl. 


III.  SYCOR  440  HARDWARE  DESCRIPTION 


The  Sycor  440  Clustered  Terminal  Processino  System  at 
NPS  is  composed  of  a control  unit  containina  a cassette  tape 
drive*  four  disolay  terminals*  a Centronix  serial  printer, 
and  a Sycor  Model  340  Communications  Terminal. 

The  control  unit  is  the  heart  of  the  440  system. 
Contained  within  a waist-hioh  cabinet  are  random  and  control 
logic  including  two  8080  chips*  64K  of  random  access  memory 
(PAM),  interfaces  for  all  oerioheral  devices*  a five 
megabyte  disk,  as  well  as  the  cassette  tane  drive. 

One  of  the  two  8080  chins  located  in  the  440  control 
unit  serves  as  the  system  CPU.  The  8080  instruction  set 
consists  of  78  data  transfer,  arithmetic*  loaical*  branch, 
stack*  I/O*  and  machine  control  instructions  (81.  Tne  Sycor 
440  provides  a comprehensive  set  of  orioritized  interrupts 
including  a timer*  peripheral  device*  and  auxiliary  storage 
device  interrupts.  Control  information  and  data  are  passed 
between  the  8080  CPU  and  peripheral  devices  through  the  T/n 
ports  (referred  to  as  latches  in  Sycor  literature)  provided 
on  the  8080  chip. 

The  second  8080  chip  found  in  the  control  unit  acts  as  a 
controller  for  the  mini-disk.  The  mini-disk  is  a sinal® 
platter*  movable  head  disk  blocked  into  SI?  byte  sectors. 
There  are  800  tracks  on  the  disk  with  13  sectors  per  track. 
Data  transfer  between  RAM  and  the  mini-disk  is  via  dire 
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memory  access  (DMA).  The  mini-disk  controller  communicates 
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with  the  host  8080  CPU  throuah  a 13  byte  disk  control  block 
(DCB)  located  at  a fixed  location  in  memory. 

Peripherals  supoorted  bv  the  Sycor  4 4 0 system  include 
synchronous  and  asynchronous  communication  devices*  up  to 
eight  display  terminals*  serial  and  line  printers*  and  card 
readers.  The  NPS  configuration  has  four  display  terminals 
consisting  of  a t yoew r i t e r- 1 i k e keyboard  and  CPT  display 
device.  Each  terminal  displays  a DMA  image  of  a 57b  byte 
terminal  buffer  located  in  R A S' . Keyboard  input  is 
accomplished  bv  software  translation  o*  a keyboard  matrix 
code  into  the  corresoondi ng  ASCII  character  code.  Per 
hardcopy  output  the  NPS  4 4 0 includes  a Centronix  serial 
matrix  Drinter. 

Several  different  auxiliary  storage  devices  mav  be 
attached  to  the  Sycor  440  in  addition  to  the  mini-dis<. 
These  include  magnetic  taoe  drives*  cassette  taoe  drives* 
and  floppy  disk  drives.  The  NPS  conf iouraf ion  includes  a 
cassette  tape  drive  located  in  the  control  unit.  This  drive 
provides  compatibility  between  the  Sycor  440  system  and  the 
Model  3 ^ 0 debugger. 

The  Model  340  Communications  Terminal  is  a complete 
system  in  its  own  right  which  is  marketed  by  Sycor  for 
remote  job  entry  (RJE)  applications  1131.  When  utilized  as 
a hardware  debugger*  the  340  is  augmented  with  4K  of  PAM  and 
a backplane  couoling  to  a special  i nt»rf ace  board  in  the  440 
control  unit.  The  340  debugger  is  provided  with  a software 
package  which  includes  provisions  for  loading  ana  dumping 
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hex  format  program  files  between  cassette  tape  and  440  RAN', 
examination  and  modification  of  individual  locations  in  440 
memory^  inserting  breakpoints  and  traps  in  programs 
executing  on  the  440»  and  s i nq 1 e-s t eop i no  through  a program 
executing  one  instruction  at  a time  1151. 

There  are  several  hardware  c ha r ac t e r i s t i c s of  the  Sycor 
44(j  system  which  strongly  influenced  the  implementation  of 
MTS.  The  most  important  of  these  are: 

(1)  b OftO  CPU  architecture 

(2 ) terminal  design 

(3)  mini-disk  interface 

(4)  s i no)  *»-st  at  e CPU 

(5)  lack  of  memory  protection 

The  impact  which  each  characteristic  had  on  tKe  design  and 
implementation  of  MTS  is  covered  in  chanters  IV  and  V.  por 


a more  detailed 

di scussion 

o f 

Sycor 

440 

hardware 

character i st ics  see 

Ref.  1 . 

?4 
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IV 


VTS  DESIGN 


MTS  was  developed  in  order  to  integrate  the  Sycor  440 
into  tte  tutorial  and  research  activities  at  NPS.  The 
oriainal  problem  definition  qiven  in  section  T.C  provided 
general  guidelines  for  acco*D 1 i sb i no  this  objective. 
Restated  briefly,  they  were: 

(1)  MTS  was  to  suooort  a suitably  modified  version  of  Cp/V 
in  order  to  provide  compatibility  with  evistina 
software  development  facilities. 

(?)  MTS  was  to  utilize  features  of  the  Sycor  operation 
system,  notably  the  Sycor  file  system,  wherever 
possible  in  order  to  reduce  development  time,  avoid 
duplication  of  facilities,  and  allow  t h e Sycor 
operating  system  to  be  used. 

(3)  MTS  was  to  provide  a man-machine  interface  at  the 
terminals  which  was  simple,  flexible,  convenient,  and 
incorporated  the  best  features  of  existino  interact  i v® 
systems  at  MPS. 

The  functions  performed  by  an  operating  system  may  be 
divided  into  the  four  major  cateaoriss  of  processor 
management,  memory  management,  file  management,  and  device 
management  (101.  The  general  guidelines  mentioned  above 
effectively  eliminated  file  management  from  cnnsideraMon  in 
the  desiqn  of  vxs.  at  the  same  time,  the  selection  of  Cp/M 
as  the  operating  system  hosted  by  MTS  provided  a familiar, 
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well-defined  model  f o use  in  determini na  the  operational 


requirements  of  the  system. 


The  following 

paraaraohs  describe 

the 

final  design 

adopted  for  the 

Microcomputer  Timeshared  System  from  four 

di f f erent 

points  of 

view 

cor  respond i no 

to  the 

four  Ta i or 

interfaces 

which 

can 

be  i dent i f i ed 

between 

MTS  and  its 

ooerat i ng 

en v i r onmen  t . 

The  internal 

view 

covers  the 

tunc  t i ona 1 

Components 

of  the 

system 

and  their 

i nterdeoendenc i es. 

The 

external  view 

deal  s 

with  t n e 

relationship  between  *■’  y s and  the  Sycor  titio  operating  system. 
The  MTS  environment  as  seen  bv  a user  prooram  is  described 
in  the  user  program  view.  The  last  of  the  four,  terminal 
user  view,  describes  the  interface  between  a terminal  user 
and  MTS,  and  the  command  processor  which  oridqes  this 
interface. 

A.  INTERNAL  VIEW 
1 . VMM  Concent 

MTS  was  orioinallv  envisioned  ;as  a software 
interface  between  the  bare  Svcor  UUO  machine  ana  uo  to  four 
user  tasks  executing  concurrently.  In  order  to  maintain 
compatibility  between  the  Svcor  440/MTS  system  and  exist ina 
NPS  microcomputer  development  facilities,  each  user  task 
would  be  provided  with  an  operating  environment  identical  to 
that  found  on  the  INTELLEC  A/MQn  »0  system. 

It  was  recoanized  that  the  Virtua1  Machine  woni tor 
concept  provided  the  simplest  and  most  eleoant  means  o* 
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implementing  such  a software  interface.  A oroperly  designed 
VMM  could  u t i 1 i ? e tne  mini-disk  included  in  the  Sycor  U 4 0 
hardware  configuration  to  simulate  the  operation  of  multiple 
floppy  disk  drives  and  provide  each  user  with  a dedicated 
virtual  printer  throuah  sooolinq.  Since  the  IMTELLEC  8 and 
Sycor  440  microprocessors  are  both  based  on  the  Intel  8080 
CPU  chip,  the  machine  lanauaqe  instruction  sets  of  the  two 
are  identical  and  interpretive  execution  would  not  ce 
necessary.  The  virtual  operating  environment  viewed  by  a 
user  task  would  be  the  same  as  that  found  on  the  IMTFLLEC 
8/MOD  80.  Additionally,  the  monitor  itself  would  be 
invisible  to  the  user. 

While  the  VMM  concept  provided  the  ideal  solution  in 
theory,  there  were  several  hardware  limitations  which 
precluded  its  implemention.  The  discussion  ot  the  V“"V 
concept  in  chapter  TI  lists  four  hardware  characteristics  of 
the  host  computer  necessary  to  implement  a practical  virtual 
machine  monitor.  These  four  characteristics  are  essential 
in  orovidina  the  reliability,  inteority,  and  protection 
required  in  a timesharing  system.  Unfortunately,  the  Tntel 
8080  chip  processors  satisfy  none  of  these  requirements. 

The  8080  is  a sinqle  state  CPU.  Mo  distinction  exists 
between  system  and  user  modes  of  operation;  consequently, 
there  is  no  need  to  provide  both  privileoed  and  non* 
orivileaed  instructions  in  the  machine's  instruction  set. 

This  makes  it  impossible  on  the  8080  to  trap  T/b 
instructions  executed  by  a user  task,  and  moans  that  all  T/0 
devices  are  accessible  to  whichever  task  currently  controls 


the  CPU 


A more  serious  problem  is  the  lack  of  memorv 
protection.  The  *0^0  provides  neither  bound  reaisters  nor 
address  translation  hardware  to  detect  memory  references 
outside  the  user  task’s  address  soace.  This  shortcominn  not 
only  made  the  VMM  concent  impractical*  but  had  a noticeable 
impact  on  the  design  finally  adopted. 

Perhaos  the  stronoest  argument  for  usino  the  V M 'A 
concept  in  implementing  a timesharing  system  is  trie 
transparency  of  the  V v M ' s operation  to  user  tasks.  Since 
each  user  task  is  effectively  running  on  an  ingependent  bare 
machine*  the  VMM  imposes  no  restrictions  on  the  user  beyond 
those  imposed  bv  the  machine's  architecture.  It  was  found 
necessary  in  the  design  of  VTS  to  compensate  to  r toe 
limitations  of  the  P0P0  CPU  bv  imposing  certain  restrictions 
on  the  freedom  of  user  tasks. 

2.  MTS  Monitor  Concept 

MTS  was  designed  to  provide  a timeshared*  virtual 
8080  microprocessor  environment  for  microcomputer  systems 
development.  The  term  "virtual"  is  appropriate  here  because 
the  user  actually  interfaces  with  MTS  for  many  services 
normally  provided  by  the  hardware  in  a dedicated  CPU 
environment.  A software  interface  between  user  programs  and 
the  Sycor  440  hardware  was  necessary  in  order  to  allocate 
the  hardware  resources  equitablv  and  efficiently,  while  at 
the  same  time  satisfying  the  service  reouirements  of  several 
competing  user  tasks. 
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The  design  of  the  MTS  interface  drew  heavily  on  the 


VMM  concept.  MTS  was  desiqned  to  multiplex  only  t h 
physical  resources  of  the  Sycor  *440  system,  i.e.  memory,  tne 
CPU,  auxiliary  storage  on  the  mini-gist*  terminals,  and 
other  peripheral  T/0  devices.  No  attempt  was  marie  to  Provide 
additional  functional  enhancements  such  as  a file  system  or 
software  development  tools.  As  stated  in  the  aeneral 
guidelines  for  the  croject,  it  was  expected  that  MTS  would 
support  a suitably  modified  version  of  the  CP/M  operating 
system,  makino  such  enhancements  reriunaant. 

The  NPS  Sycor  440  hardware  configuration  dig  not 
include  floppy  disk  as  an  auxiliary  storage  medium.  Since 
floppy  disks  are  provided  ov  the  INTELLFC  S/MOD  b 0 systems, 
and  are  necessary  to  run  CP/M,  it  was  decided  to  implement 
virtual  flooov  disks  and  disk  drives.  Provisions  were  also 
made  to  expand  the  system  to  include  virtual  printers,  card 
readers,  oaoer-taoe  readers,  and  other  dedicated  T/0  devices 
at  a later  date. 

As  a timesharino  system,  MTS  is  characterized  by  the 
following  major  features: 

(1)  the  use  of  swapping  to  implement  mu  1 t i p roo r amm i ng 

(2)  the  use  of  interrupt  driven  processor  management  based 
on  a round-robin  scheduling  alaorithm 

(3)  the  use  of  virtual  floppy  disks  as  the  primary 
auxiliary  storaoe  medium 

(4)  the  sharing  of  a single  dedicated  T/0  device  r v 


multiple  users. 


and  the  following  charter 


3.  Memory  Manaqement 

The  Sycor  440  provides  64*  bytes  of  random  access 
memory.  Sliqhtly  over  3K  bytes  of  this  is  required  for 
terminal  and  cassette  DMA  buffers*  a ROM  bootstrap  proo  r am , 
a mini-disk  control  block*  and  interrupt  processino.  Tn« 
decision  was  made  that  a minimum  of  4RK  contiauous  bytes  of 
memory  would  be  made  available  to  user  tasks  with  the 
remaininq  13K  bvtes  reserved  for  the  resiaent  portions  of 
MTS.  This  estimate  of  the  amount  of  memory  reauired  bv  VTS 
was  based  in  part  on  the  size  of  the  CP/M  operatino  system 
and  was  intentionally  oenprous  to  oroviae  sufficient  memory 
for  future  growth  and  enhancement  of  MTS  facilities. 

Once  a decision  had  been  made  on  the  amount  of 
memory  available  to  user  tasks  it  was  necessary  to  select 
the  ootimum  method  of  manaoinq  this  memory  space.  This 
decision  also  was  strongly  influenced  by  hardware 
considerations.  The  Tntel  n0P0  CPU  provides  only  a sinole 
direct  addressing  mode.  Since  the  Sycor  4a0  proviaes  no 
address  translation  hardware*  the  more  advanced  memory 
manaqement  techninues  such  as  paqinq  and  dynamic 
partitioning  were  infeasible.  The  only  practical  choices 
seemed  to  De  swapping  or  a static  partition i no  scheme. 

The  static  partition  approach  was  considered 
carefully  since  it  offered  several  advantages  over  swapping. 
Most  importantly*  a memory  management  technique  which  does 
not  involve  data  transfers  between  memory  and  auxiliary 
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storage  would  be  much  faster  than  swappinq.  Static 
partitioning  offered  the  added  advantage  of  simplicity, 
dith  all  user  programs  resident  in  memory  it  would  not  oe 
necessary  to  maintain  tables  showina  the  disk  addresses  of 
blocked  or  ready  tasks. 

There  was  a single  overriding  factor  which 
ultimately  mandated  the  selection  of  swapoina.  A 
timesharing  system  must  maintain  the  intearity  of  aP 
concurrently  executing  tasks.  Since  the  Sycor  <440  provides 
no  memory  protection/  this  would  he  impossible  if  two  or 
more  tasks  were  resident  in  memory  simultaneously.  hot  only 
would  it  be  impossible  to  prevent  one  task  from  accession 
another/  it  would  be  impossible  to  detect  the  occurrence  o* 
a reference  out  of  bounds. 

The  use  of  swapnina  provides  physical  as  well  as 
logical  separation  of  all  user  tasks  in  the  system. 
Associated  with  each  of  the  four  terminals  is  a mini-aisk 
file  used  to  store  a memory  image  of  that  terminal's  current 
task  when  it  is  waiting  for  the  CPU  or  blocked  oendino  some 
I/O  operation.  At  any  qiven  instant  a task  may  reside  on 
the  mini-disk  in  its  swao  file  or  in  memory/  but  at  no  time 
can  two  or  more  tasks  be  resident  in  memory  simultaneously. 

Swappina  also  makes  available  to  each  task  tne 
entire  4PK  user  area  of  memory  as  originally  planned.  tven 
though  few  users  will  ever  write  a sinale  prooram  which 
requires  the  entire  48k  bytes/  the  additional  memory  does 
enhance  the  operation  of  CP/M  development  tools  such  as  the 
text  editor  by  allowing  laroer  buffers  and  fewer  disk 
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While  the  incorporation  o * swaopina  into  MTS  did 
solve  the  problem  of  maintaining  task  integrity,  it  also  had 
the  undesirable  side  effect  of  makina  the  mini-disk  data 
transfer  rate  the  limiting  factor  in  system  responsiveness. 
Based  on  informal  timing  figures  orovided  bv  Sycor,  it  was 
estimated  that  as  long  as  six  seconds  may  be  required 
between  timeslices  to  handle  the  swapoing  of  two  bfaK  hvte 
tasks.  This  problem  was  recognized  earlv  in  the  oesian 
phase  of  development  and  solutions  were  sought  in  several 
areas.  A partial  solution  to  the  problem  is  offered  ny  an 
improved  mini-disk  controller  under  development  at  Sycor  as 
this  was  written.  Preliminary  tests  have  shewn  that  this 
imoroved  controller  will  improve  the  mini-disk  transfer  rate 
ov  a factor  of  from  three  and  one-half  to  four  over  its 
present  value. 

Several  features  have  been  included  in  the 
design  to  minimize  the  delay  inherent  in  swapping.  For 
example*  the  system  default  size  was  limited  to  16K  bytes  in 
an  effort  to  reduce  the  size  of  the  memory  imaoe  which  must 
be  transferred  to  the  mini-disk.  A user  can  specify  a 
larger  memory  size  if  required,  but*  in  the  absence  of  an 
explicit  reouest  for  more  memory*  lbK  bytes  is  assumed. 
Consideration  was  also  given  to  minimizing  the  freouency  of 
memory  image  transfers.  The  scheduler  was  designed  to  defer 
swapping  until  it  determined  that  a different  memory  image 
was  required  to  continue  processing.  As  an  illustration, 
consider  the  case  of  a single  task  active  on  the  system.  If 
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swappina  is  not  deferred,  this  sinale  task  will  constantly 
thrash  back  and  forth  between  memory  and  the  mini -disk.  8v 
deferring  each  swao  until  it  is  absolutely  necessary,  tnp 
overhead  due  to  swaopina  becomes  roughly  proportional  to  the 
number  of  active  tasks  minus  one,  or  zero  for  a sinole  task. 

4.  Processor  Management 

An  assumption  basic  to  the  entire  MTS  deve  1 corner,*- 
effort  was  that  MTS  would  support  m i c r oc omou t e r systems 
development.  This  assumption  implies  tha*  at  any  one  time 
some  of  the  tasks  active  on  the  system  may  reouire 
relatively  large  amounts  of  CPU  time  while  others  ray  t;e 
blocked  oenoino  terminal  I/O.  Tn  order  to  ensure  that  t ne 
CPU  resource  is  allocated  fairly  to  all  active  tasss  it  was 
decided  to  implement  an  interrupt  driven  t as  * schedule**. 
Each  task  is  allocated  the  CPU  for  a fixed  interval  of  time 
called  a timeslice.  A task  retains  control  o*  the  CPU  u n *•  i l 
a hardware  timer  generates  an  interrupt  siqnalina  the 
expiration  of  the  task's  timeslice.  The  timer  interrupt 
handler  then  transfers  control  to  the  task  scheduler  to 
select  a new  task  for  execution. 

Notice  that  interrupt  processina  is  carried  out 
independently  of  task  schedulinq.  This  could  cause  a 
problem  if  a timer  interrupt  should  occur  while  system  code 
is  oeing  executed.  The  task  currently  resiaino  in  memory 
would  be  swaooed  out  reaardless  of  its  status.  This  problem 
was  resolved  by  desianino  MTS  to  set  a software  lock  each 


time  it  is  entered.  The  timer  interrupt  handler  checks  this 


lock  whenever  a timeslice  expires  and  suppresses  swarpi nq 


until  the  lockout  condition  has  been  cleared, 
b.  Virtual  Flooov  Disks 

The  MTS  virtual  flooov  disk  drive  provides  auxiliary 
storage  for  user  programs  on  virtual  floppy  disxs.  Th»s<* 
simulated  hard-sectored  disks  have  128  bytes  oer  sector,  26 
sectors  per  track,  and  a maximum  number  of  tracks  determined 
bv  the  size  of  the  mini-disk  file  containino  the  disk  imane. 
Each  user  has  eight  drives  available  for  dedicated  use. 

A virtual  flooov  disk  resides  on  a block  of 
loqically  contiguous  mini-aisk  sectors.  where  a physical 
flooov  disk  has  a fixed  capacity  of  256k  bytes,  an  h'T'5 
virtual  disk  may  have  any  convenient  size.  '^TS  assumes  that 
the  disk  image  is  made  up  of  contiguous  IPS  by te  floppy  disk 
sectors  Starting  with  track  0 sector  1,  proceeoino  throuah 
the  26  sectors  of  track  0 to  track  1 sector  1,  and  so  on 
until  the  virtual  disk  file  is  full. 

In  order  to  access  a virtual  floppy  aisk  a user 
program  must  provide  MTS  with  a complete  sector  address  and 
the  base  address  of  a 128  byte  DMA  buffer  in  the  user's 
memory  space.  This  buffer  derives  its  name  from  the  nature 
of  the  data  transfer  operation:  to  the  user  program  it 
appears  that  data  is  transferred  between  his  program  and  the 
virtual  flooov  disk  bv  direct  memory  access. 

A complete  sector  address  consists  of  a virtual 
drive  number  and  the  virtual  disk  sector  and  track  numhens. 
With  this  information  MTS  can  calculate  the  offset  of  the 
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addressed  sector  in  the  mini-disk  file 


validate  that  the 


addressed  sector  is  within  the  file*  ana  read  the  mini-disk 
sector  into  memory  for  transfer  of  the  specified  12b  bytes 
to  the  user's  DMA  buffer. 

The  mapoing  function  used  to  convert  a complete 

sector  address  into  a mini-disk  sector  number  is  based  on 
two  facts: 

(1)  The  virtual  floppy  disk  imaoe  is  stored  as  a linear 

array  with  the  sector  number  increasing  most  rapidly 

and  the  track  number  increasing  least  rapidly. 

(2)  The  mini-disk  file  containing  the  virtual  disk  image 
is  a single  contiauous  block  of  512  byte  sectors. 

Recogni7ina  that  the  virtual  disk  image  is  stored  as  a 

linear  array,  the  offset  of  any  virtual  disk  sector  in  th® 
file  becomes 

vs. offset  = (2b  * track. nr)  + sector. nr. 

Aoplyinq  the  fact  that  each  512  bvte  mini-disk  sector  may 
contain  up  to  four  virtual  floppy  disk  sectors,  the  file 
offset  and  position  of  the  specified  virtual  disk  sector  in 
the  mini-disk  buffer  can  now  be  calculated. 

file. offset  = vs. offset  DIV  4 
buf.pos  = (vs. offset  PEM  u ) * 128 
where  DIV  and  REM  represent  inteqer  division  and  remainder 
respectively.  Once  the  file  offset  is  known,  it  is  a simple 
matter  to  add  this  value  to  the  file's  base  sector  numper  to 
complete  the  manoino.  Similarly,  the  buffer  position  is 
added  to  the  mini-disk  buffer's  base  address  to  fina  the 
current  memory  address  of  the  specified  virtual  disk  sector. 
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B.  PROTECTION  AND  RECOVERY 


Thus  Tar  in  the  discussion  of  MTS  desiqn  features  tne 
topic  of  protection  has  already  been  encountered  several 
times.  It  has  been  stated  that  the  inderenaence  of 
concurrently  executing  processes  must  be  maintained*  and 
that  orotection  is  also  necessary  for  the  operating  system 
itself.  Due  to  the  architecture  of  the  Syccr  u 4 0 system,  a 
great  deal  of  consideration  was  qiven  to  the  protection 
problem  as  well  as  the  related  tonics  of  recovery  and 
o r i vac  y . 

1 . System 

MTS  maintains  the  independence  of  concurrently 
executing  user  tasks  by  enforcing  physical  separation 
through  swapping.  This  techniaue  is  practical  and 
effective,  but  only  deals  with  part  of  the  protection 
problem.  It  is  even  more  important  that  WTS  itself  ce 
protected  from  user  tasks.  Situations  in  which  a user  task 
may  inadvertently  overlay  or  modify  pieces  of  system  code 
must  be  avoided.  At  best  this  could  lead  to  a system  crash 
with  varying  degrees  of  impact  on  all  system  users?  at 
worst,  MTS  could  continue  processing  in  an  erratic  fashion 
which  causes  irrecoverable  damage  to  user  files.  The  first 
situation  is  immediately  obvious  to  the  system  users?  the 
second  may  oo  undetected  for  just  long  enough  to  b*> 
cat  ast  roph i c . 

The  technique  used  to  protect  user  tasks  from  one 
another  cannot  be  applied  to  this  new  problem.  while  it  is 
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feasible  to  make  some  sections  of  the  system  such  as  th* 


■ 
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task  scheduler  or  terminal  command  processor  non-resident 
and  swap  them  in  as  required*  there  are  other  system 
functions  such  as  interrupt  handlers  which  must  be  resident 
at  all  times.  One  oossible  solution  to  the  problem  would  be 
storing  all  system  code  in  read  only  memory  with  oackun 
copies  of  all  system  data  maintained  on  the  mini-disk.  The 
simplicity  of  this  anoroach  makes  it  acoealino,  but 

nevertheless  impractical  for  reasons  discussed  in  the 
external  vi  of  w T S presented  in  section  IV.C.1. 

After  a great  deal  of  consideration*  no  practice), 
effective  method  of  crovidim  system  protection  cou'o  foe 
found  which  did  not  involve  imposing  an  unacceptable  amount 
of  orotection  overhead  on  the  system.  Tn  lieu  of  a 
protection  scheme  it  was  decided  to  incoroorate  a recovery 
capability  into  the  MTS  design.  It  was  felt  that  the 
ability  to  recover  araceful I y from  occasional  inadvertent 
system  crashes  would  compensate  somewhat  for  the  lack  of 
adeauate  system  protection. 

Three  different  types  of  information  were  identified 
as  being  necessary  to  the  implementation  of  a recovery 
capability.  They  were: 

(1)  a copy  of  each  user  task's  latest  memory  image* 

(2)  copies  of  all  current  values  for  system  control 
variables  and  tables* 

(5)  the  identity  of  the  task  runnino  when  the  crash 
occurred. 

The  use  of  swapping  made  the  first  tyoe  of  information 
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readily  available  on  the  mini-disk  with  no  aaditional  action 
required.  To  this  ooint  in  the  design  it  had  not  been  found 
necessary  to  save  the  values  of  svstem  control  variables  and 
tables  anywhere  other  than  in  memory.  This  deficiency  was 
rectified  by  introducing  the  concept  of  a system  state  block 
( SSB ) . 

The  SSB  consists  of  a compact/  contiguous  aata  block 
in  the  system  area  of  memory  containing  all  control  data 
defining  the  state  of  the  system  at  each  instant.  The 
includes  information  such  as  the  status  of  each  user  *-ask, 
virtual  floppy  disk  assignments/  the  location  of  each  swan 
file  on  the  mini-disk/  the  identity  of  the  task  cutrcnHv 
allocated  the  CPU/  ana  the  protection  attributes  and 
locations  of  all  virtual  disk  files.  In  order  to  have  this 
information  available  should  recovery  be  reouireo/  the  Sob 
is  copied  to  the  recovery  file  whenever  the  state  of  toe 
svstem  changes. 

Taken  together/  the  four  swao  files  and  the  recovery 
file  contain  sufficient  information  to  restore  normal 
execution  after  a system  crash.  The  third  item  required  for 
recovery/  the  identity  of  the  task  causing  the  crash,  is 
needed  to  delete  the  faulty  task  from  the  svstem.  The  swan 
file  for  this  task  contains  a duplicate  of  the  memory  image 
which  has  just  caused  the  svstem  failure.  If  this  same  task 
were  reloaded,  another  s y s t “ m crash  would  likely  occur. 

One  final  point  must  be  mentioned  to  complete  tne 
discussion  of  system  protection,  and  that  is  access 

projection.  Most  general  purpose  timesharing  systems  emplov 
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some  type  of  code  to  identify  individual  or  group  users  of- 
the  system.  This  code  may  be  used  in  the  collection  of 
utilization  or  accounting  statistics*  or  simply  to  identify 
authorized  users  of  the  system.  It  was  decided  that  the 
access  protection  provided  by  such  a code  is  not  a necessary 
requirement  for  MTS.  The  N P S microcomouter  laboratory  '-as 
generally  followed  an  open  door  policy  which  permits  anyone 
with  an  interest  in  microcomputers  to  use  the  available 
facilities.  Conforming  to  the  spirit  of  t n i s open  lab 
policy*  access  protection  is  not  implemented  in  VTS. 

2.  Virtual  Floppy  Disks 

The  protection  issue  surfaced  for  the  third  time  in 
the  implementation  of  virtual  floorv  disks.  In  this 
context*  protection  implies  privacy  and  security  for  virtual 
f 1 oppv  disk  files. 

From  the  viewcoint  of  privacy  ana  security  of  data* 
floppy  disks  provide  an  auxiliary  storaae  meaium  surpassed 
by  few  others.  The  physical  disk  is  small  in  size  and 
convenient  to  carry  or  store*  vet  provides  a storage 
capacity  of  kilobytes*  eauivalent  to  1.6  card  sleeves. 
When  an  individual  finishes  an  operating  session  on  a s v s *■  em 
equipped  with  floppy  disk  drives*  he  need  only  physically 
remove  the  disk  from  the  drive  to  provide  whatever  physical 
protection  the  contents  merit. 


The 

virtual  f 1 oopy 

disks  provided  bv 

MTS 

do  not 

afford 

the 

same 

degree 

o f 

privacy  or  security 

as  a 

Physical 

disk. 

With 

the 

Syco  r 

440  hardware  c on f i gu r a t i on  which 

existed  when  this  was  written,  it  was  not  possible  r o cocv  a 


virtual  floppy  disk  i maqe  onto  a physical  disk  for 
safe  x eep i ng . 

In  order  to  provide  a limited  deqree  of  protection 
for  virtual  floppy  disks  it  was  decided  to  provide  three 
different  protection  attributes  for  virtual  f 1 oopv  disk 
files: 

(1)  no  protection  - unlimited  access  for  read  or  write 
(21  restricted  - unlimited  access  for  r»ad  only,  wri  tp 
access  only  if  the  file's  protection  key  is  known 
(3)  protected  - read  and  write  access  only  if  the  file's 
protection  key  is  known. 

The  first  option,  no  protection,  applies  to  scratch 
disks  provided  for  temporary  sf orane  or  work  space.  Such 
files  should  be  available  to  any  user  as  reouired.  T r,  e 


restricted 

attribute 

a 1 lows 

the 

owner  of  a oiven  vi 

r t IJ  a 1 

disk  file  to 

make  the 

contents 

0 f 

the  file  avail ab 1 

e to 

others  on  a 

read  only 

basis. 

This 

level  of  protection 

w o u 1 d 

apply  to  the  system  disk  containino  the  CP/'W  operatina 
system.  The  protected  attribute  provides  complete 
protection  for  a virtual  disk  file.  \'o  one  other  than  the 
file's  owner  or  someone  designated  by  the  owner  can  access 
the  file  either  to  read  or  write. 

Since  ^TS  does  not  reauire  user  identification 
codes,  the  protection  kev  feature  was  adopted  to  identify 
the  owner  of  a virtual  disk  file.  4 protection  key  mav  be 
any  compination  of  zero  to  four  ASCII  characters  associated 
with  a virtual  disk  file  when  the  restricted  or  protected 


attribute  is  set 


. The  same  Drotection  kev  must  be  / supplied 
by  a user  attemptina  to  write  to  a restricted  file  or  read 
and  write  to  a protected  file. 

C.  EXTERNAL  VIEW 

when  the  Sycor  440  Clustered  Terminal  Proressi no  System 
was  delivered  to  the  NPS  microcomputer  laboratory#  t r,  e 
shipment  included  an  extensive  oackaqa  of  software  in 
addition  to  the  hardware  listed  in  chapter  III.  Tn« 
existence  of  this  software  had  a sianificant  imoact  on  the 
desiqn  of  MTS.  The  nature  and  extent  of  this  impact  is 
discussed  in  the  followina  paraqraohs. 

1.  Svcor  440/ MTS  Interface 

The  Sycor  440  system  demonstrates  one  way  in  which 
microcomputer  technology  has  been  aoolied  to  commercial  data 
processing.  The  440  system  is  marketed  for  applications  in 
the  field  of  data  entry#  in  particular  data  entry  at 
locations  remote  from  a central  processino  facility.  This 
intended  application  is  readily  apparent  in  the  software 
provided  by  Sycor  - formatted  and  unformatted  keyboard 
input#  remote  job  entry#  report  generation#  communications# 
an a on-site  file  enquiry  ar»  prominently  featured.  The  440 
operating  system  and  file  manaoement  facilities  also  reflect 
the  emphasis  on  data  entry.  *'ost  of  the  oroorammino  aids 
which  are  important  in  a system  development  environment  are 
not  provided  by  the  Sycor  440  software  oackaqe.  Them  is  no 
text  editor#  8080  assembler#  debuqainq  orooram#  or  8080  t>ex 
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format  loader.  The  ooeratinq  system  is  larne,  allowing  only 
limited  memory  soace  for  user  developed  programs.  Further, 
the  mini-disk  file  system  is  oriented  around  static 
allocation  of  fixed  size  files. 

The  Sycor  400  operating  system  and  associated 
utility  proarams  are  well  suited  to  the  data  entry 

application  for  which  they  were  designed.  At  the  same  time, 
they  do  not  provide  a suitable  environment  for  m i c r oc om ou t e r 
systems  develooment.  This  fact  provided  the  initial 

motivation  for  the  development  of  MTS. 

Once  the  decision  had  been  reached  to  desian  and 
implement  a separate  system  to  support  systems  development 
on  the  Svcor  440  hardware  there  were  basically  two  options 
ooen  with  regard  to  the  Sycor  suoolied  software: 

(1)  remove  the  Sycor  ooeratina  system  and  associated  ois^ 
files  to  make  more  memory  ana  disk  space  available  for 
MTS 

(2)  design  MTS  so  that  both  systems  might  be  available 
concurrent  1 y . 

Option  2 had  the  desirable  effect  of  makino  available  a 
resident  COBOL  compiler  and  a PLMR  cross-compiler,  both  of 
which  are  supported  bv  the  Sycor  ooeratina  system.  Option  1 
allowed  the  greater  flexibility  in  the  cesiqn  of  MTS,  but 
reduced  somewhat  the  overall  capabilities  of  the  Sycor 
440/MTS  comoination.  The  deciding  factor  in  selectino  the 
second  option  for  implementation  was  a desire  to  furnish  the 
system  af fordina  the  maximum  potential  for  future 
development  while  still  meeting  project  goals. 
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2.  File  System 


r 

The  decision  to  make  the  Sycor  operating  system  and 
MTS  concurrently  available  made  it  possible  to  i rro  1 omen  t MIS 
without  designina  a file  system.  The  file  management 
facilities  provided  bv  the  Sycor  ooeratina  system  proved 
adequate  to  handle  swsoDinq,  recovery,  and  virtualized 
floppy  disks.  Constraininq  each  file  to  a predetermined 
fixed  size  was  not  difficult;  in  fact,  this  feature  of  the 
Svcor  file  system  simolified  considerably  the  virtual  cisk 
mapping  function  on  which  the  entire  virtual  f ' oopv  0’sk 
design  was  based . 

Four  different  types  of  files  w»re  included  in  the 
final  MTS  design.  They  are: 

(1)  swap  files  - four  files,  one  of  which  is  associated 
with  each  of  tne  four  terminals,  containing  a user 
program  memory  image 

(2)  recovery  fi’e  - a si nol e-sector  file  containing  a 
current  copy  of  the  system  state  block 

(3)  configuration  file  - a sinqle-sector  file  containing 
the  user  defined  name  and  protection  attribute  for 
each  virtual  floppy  disk 

( a ) virtual  floppy  disk  files  - a maximum  of  32  different 
files,  each  containing  the  image  of  a f 1 opdv  disk  as 
described  in  section  IV. A. 5. 

Three  of  these  four  file  types  have  been  encountered  before, 
but  the  configuration  file  tvoe  requires  some  additional 
explanation.  MTS  identifies  virtual  disks  by  a logical  disk 
number  in  the  range  0 to  31.  Since  each  virtual  floppy  disk 
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actually  resides  in  a mini-disk  file  created  under  the  Sycor 
onerating  system,  there  must  he  some  mechanism  for  manpino  a 
logical  disk  number  into  a file  name  contained  in  the  mini- 
disk directory.  There  is  an  additional  requirement  that  the 
protection  attributes  assiqned  to  various  virtual  disk  files 
be  saved  between  MTS  operatina  sessions.  both  of  these 
functions  are  performed  bv  the  configuration  file. 

The  con f i ou rat i on  file  is  made  up  of  32  entries  of 
thirteen  bytes  each  contained  on  a sinole  mini-disk  sector. 
Each  entry  is  composed  of  a zero  to  eight  bvte  filename,  a 
zero  to  four  bvte  protection  key,  and  a sinole  t.vte 
protection  attribute.  The  loaical  disk  numpe  r for  each 
entry  is  simply  the  position  of  that  entry  within  the  file. 

In  order  to  reduce  the  number  of  mini-disk  accesses 
required  to  service  virtual  flooov  dis*  I/O  requests,  it  was 
decided  to  read  the  corf iquration  file  into  memory  only 
once,  during  MTS  initialization,  and  abstract  the  contents 
into  an  internal  data  structure  resident  in  memory.  This 
concept  was  expanded  later  to  include  the  mini-disk  file 
directory  as  well.  That  too  is  read  into  memory  durina 
initialization  and  searched  for  all  four  m j S file  types. 

D.  USER  PROGRAM  VIEW 

The  MTS  user  program  interface  consists  of  a set  of 
service  routines  which  may  be  called  by  a user  croaram 
throuoh  a sinale  entry  point  to  perform  terminal  I/O,  access 
virtual  floppy  disks,  or  modify  the  user's  virtual 
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env i ronment 


The  design  was  heavily  influenced  by  the  CP/m 


operating  system  which  uses  a similar  scheme  for  I/O  [?)  . 

The  use  of  explicit  calls  to  MTS  for  I/P  was  an  undesirable 

limitation  necessitated  by  the  architecture  of  the  P 0 P 0 CPU. 
Since  the  8080  is  a sinale-state  machine  without  privileaed 
instructions,  the  hardware  orovides  no  facilities  for 

trapping  I/O  instructions. 

A call  to  MTS  takes  the  form 

<value>  ~ MTS(<fid>,<oarm>). 

The  first  argument,  <fid>,  is  a number  which  iuentifies  the 
function  to  MTS.  The  <rarm>  argument  may  be  a parameter 
value,  if  only  a single  oara*eter  is  required,  or  trip 
address  of  a parameter  list  if  more  than  one  is  neeaed.  In 
each  case,  MTS  returns  <value>  upon  completion  of  th» 

requested  operation.  This  returned  value  *av  be  an  A ST  I T 
character  code,  an  error  code,  or  znro  if  the  value  has  no 
s i gn i f i canc e . 

The  services  available  to  a user  may  be  loaicallv 
divided  into  two  types  of  calls  on  MTS:  (1)  system  calls, 

and  (2)  service  calls.  System  calls  handle  creating, 

v 

modifying,  and  deleting  attributes  of  a user's  virtual 
environment.  As  a minimum,  each  user  is  provided  with  a 
virtual  system  consisting  of  an  6080  CPU,  IbK  bytes  of  PA M , 
a terminal,  and  a single  floppy  disk  drive  with  a reao-onlv 
copy  of  the  C P/m  operating  system  loaded.  T i s 
configuration  is  the  system  default  environment  assumed  whpm 
the  user  loos  in.  Beyond  that  the  us»r  may  reguest: 

(1)  additional  memory  up  to  a maximum  of  48*  bytes 
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( 2 ) additional  floppy  disk  drives  uo  to  a maximum  of  P 

(3)  attachment  of  any  virtual  floppy  disk  whose  protection 
key  is  known 

(4)  reboot  of  the  user's  system  from  drive  A . 

Each  system  call  performs  the  ime  function  for  a user 
program  as  the  corresponding  terminal  system  command 
performs  for  the  user  at  a terminal. 

Service  calls  provide  a user  nrogram  with  access  to  the 
terminal i virtual  printer.  and  virtual  f lorcv  disks.  The 
details  of  the  terminal  interface  are  oiscussea  more  tullv 
in  section  IV. F.  In  the  context  of  service  calls,  it  is 
important  to  note  that  attempting  to  read  from  a terminal 
when  no  input  is  waitina  will  cause  the  mouestina  task  to 
be  swapped  out  and  blocked  until  input  is  available. 

Before  a user  procram  can  access  a particular  virtual 
disk.  the  user  must  attach  that  disk  to  one  of  the  eioht 
virtual  disk  drives,  either  bv  making  a system  call  to  MTS. 
or  entering  the  prooer  system  command  at  the  terminal.  Unce 
a virtual  disk  has  been  attached.  any  sector  within  that 
disk  is  accessed  by  srecifyina  a complete  sector  address  and 
a DMA  buffer  address.  VTS  provides  a service  call  to  enter 
each  of  the  three  components  of  a complete  sector  address  or 
the  DMA  buffer  base  address  as  well  as  additional  calls  to 
read  or  write  the  specified  sector. 

In  the  section  which  discusses  the  VMW  concert  it  was 
mentioned  that  transparency  to  the  user  is  an  important 
characteristic  of  a VWM . The  attempt  was  maoe  in  the  design 
of  MTS  to  incorporate  this  same  feature.  nue  to  the 
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hardware  constraints  imposed  by  the  8080  CPU,  this  attempt 
was  not  entirely  successful.  There  are  several  places  in 
the  user  orogram/MTS  interface  where  the  operation  of  ^'TS 
could  not  be  hidden.  The  necessity  for  explicit  calls  to 
MTS  for  I/O  services  has  already  been  mentioned.  The  manner 
in  which  interrupts  are  handled  by  the  8080  also  impacts  on 
a user  program.  Since  the  only  addressi nn  mode  provided  tv 
the  8080  is  direct  addressing,  the  fact  that  WTS  and  a 
user's  program  occupy  the  same  physical  memory  is  apparent 
to  a user  proaram  bv  the  limits  on  the  user's  address  snace. 

E.  terminal  USFR  VIEH 

The  primary  interface  between  the  terminal  user  and  WTS 
is  provided  by  a command  language  interpreter  called  the  "TS 
Command  Processor  (MCP).  This  interface  provides  the  user 
with  the  facilities  necessary  to  establish  and  modify  the 
working  environment.  The  user  can  gain  access  to  UTS 
through  system  commands  at  any  time,  even  though  currently 
communicating  with  a subsystem  such  as  CP/M  or  other 
proarams.  Access  is  accomplished  bv  enterinq  the 
appropriate  command  at  the  terminal,  terminated  bv  the  ERD(JD 
RESET  key.  This  sianals  the  MTS  monitor  that  the  input  data 
is  a system  command  to  be  processed  by  MCP. 

1.  MTS/MCP  Interface  Desiqn 

One  of  the  desiqn  cons i de r a t on s for  a command 
orocessor  in  an  interactive  timeshared  environment  is 
whether  it  shall  be  resident  or  non-resident. 
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The  actiors 


required  to  establish  and  modify  the  user's  environment  are 


not  normally  time  sensitive  nor  continuously  exercis'd  by 
the  user.  For  these  reasons*  recent  timesharinq  systems 
have  commonly  implemented  the  command  processor  as  a non- 
resident task  (lol.  Fstablishinq  MCP  as  a non-resident* 
swappable  task  was  qiven  serious  consideration.  However, 
one  of  the  major  Sycor  440  hardware  limitations  affectinq 
the  implementation  of  MTS  was  t h • relatively  low  aata 
transfer  rate  between  memory  and  the  mini-disk  fI.A.3).  To 
meet  the  qoal  of  reasonable  system  response*  minimis i no  th» 
number  of  swaooino  tasks  became  one  of  the  MTS  design 
constraints. 

The  decision  was  made  to  desion  MCP  as  a resident 
but  completely  independent  module  of  MTS.  This  concept 
makes  the  MCP/MTS  interface  essentially  the  same  as  that 
between  any  users  prooram  and  MTS.  MCP  affects  changes  in 
the  user’s  virtual  environment  by  calls  to  v T S in  the  same 
manner  as  would  a user  prooram.  There  are  two  primary 
differences  between  the  MCP/MTS  interface  and  a user 
prooram/MTS  interface: 

(1)  The  entry  port  used  by  MCP  is  an  internal  MTS  entry 
point.  MTS  also  provides  an  external  entry  point  for 
use  by  user  procrams.  The  requirement  for  two  entrv 
points  resulted  from  the  decision  to  make  f he  MCP  a 
resident  process.  The  distinction  is  necessary  to 
bypass  the  mechanism  which  blocks  user  pronrams 
requesting  terminal  input  when  the  incut  buffer  is 
empt  y . 
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( 2 ) MCP  must  save  and  restore  the  MTS  system  stack  do  inter 


t o 

ensure 

returning  to 

the  proper  1 oc a t 

ion  in  the 

MTS 

mon  i 

tor. 

User  programs 

do  not 

directly 

i nterfare 

with 

the 

MTS 

monitor,  and 

thus 

are  not 

concerned 

with 

saving  and 

restoring  its 

stack 

pointer. 

The  independence  of  data  structures  ana  system  call 
interface  features  were  maintained  for  ease  of  implementinn 
MCP  as  a swappable  image  at  some  future  time.  Upgrading  tne 
Sycor  440  mini-disk  controller  soeed  ana  an  increase  in  the 
number  of  system  commands  available  to  the  user  would 
justify  imnlementing  the  MCP  as  a non-resident  swaroable 
task. 

2.  r>ystem  Commands 

Since  the  system  command  language  is  the  terminal 
users  main  ooint  o*  contact  with  MTS»  the  features  and 
syntax  were  given  careful  consideration.  The  desian  ooals 
were  to  develop  a command  language  which  is  easy  to  learn 
and  easy  to  use. 


There 

are 

two 

basic 

sets 

of  system 

Commands 

available  to 

the 

user. 

One 

set  of 

commands  allow 

the  user 

to  establ i sh 

and 

modi f y 

the 

environment.  These 

i nc 1 ude 

linking  the  terminal  to  MTS  (L0dM)»  specifying  virtual  oisk 
drives  and  virtual  flooov  disks  to  be  attached  to  the 
environment  (ATTACH);  changing  the  memory  image  swap  size 
allocation  (SIZE)*  and  unlinking  from  MTS  (QUTT). 

The  second  set  of  commands  provide  the  user  with  a 


means  of  specifying  protection  attributes  for  virtual  floorv 


disk  files 


These  include  adding  the  orotect  ion  attribute 


to  a specif i ed  virtual  floppy  disk  (PROTECT);  addino  tre 
restricted  attribute  to  a protected  virtual  florpv  disk  to 

allow  read  access  bv  other  us®rs  (RESTRICT);  and  to  remove 

s 

all  previous  protection  attributes  from  a virtual  florpv 
disk  (UNPROTECT). 

The  function,  syntax,  parameters,  description  and 
associated  error  messaaes  for  each  command  are  described  in 
detail  in  section  0.3  of  Appendix  A. 

F.  TERMINAL  INTERFACE  DESIGN 

The  four  terminals  attached  to  the  Sycor  440  s v s t e m 
provide  the  user  with  a CRT  display  and  tycewri ter-1 i ke 
keyboard  for  entering  data.  A brief  description  of  fhe 
terminal  hardware  is  contained  in  chapter  IIT.  The  'actors 
affecting  the  terminal  interface  desian  included: 

(1)  Lonq  delays  between  key  depression  and  appearance  of  a 
character  on  the  terminal  display  are  unacceptable  to 
the  user. 

(2)  The  characters  displayed  at  each  terminal  are  a DMA 
image  of  characters  located  in  the  Svcor  440  main 
memory . 

(3)  The  terminals  have  very  primitive  hardware  display 
logic.  Thus  software  is  reauired  to  accomplish  such 
tasks  as  converting  a keyboard  matrix  code  to  ASCII 
code  for  each  key  depression,  cl  inkina  the  current 
position  indicator  (cursor),  and  scrol 1 inn  th» 
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d i so  1 ay  . 

1.  Design  Decisions 

MTS  was  desicned  To  provide  a virtual  terminal 
interface  for  programs  reouestinq  terminal  I/O.  This 


interface 

simulates 

the 

ooe  r a t ion 

of  a 

serial 

half -dup 1 e x 

console 

device. 

For 

input  of 

data. 

the  user  program 

regues t s 

characters 

one 

at  a time 

through 

service 

calls  to 

MTS.  If 

i npu  t i s 

ava  i 

Table,  the 

next  character 

is  returned 

to  the  reauest inq  proaram.  Outout  is  handled  in  a similar 
fashion  with  the  user  proarao  providing  an  ASCII  character 
code  as  an  arourent  in  the  appropriate  service  call.  A 
service  call  is  made  for  each  character  to  be  aisclayeo. 
For  each  request  received  oy  M T S , the  character  is  displayed 
bv  placing  it  at  the  current  cursor  position  in  tn» 
appropriate  terminal's  DMA  display  buffer.  The  only 
characters  not  olaced  in  the  display  buffer  on  output  are: 
carriage  return  (C^).  which  returns  the  cursor  to  tne 
leftmost  position  of  the  current  line;  and  line  feed  (LF), 
which  moves  the  cursor  position  down  one  line.  The  outout 
of  a data  seauence  is  normally  terminated  by  a Ch/LF 
character  combination.  MTS  also  provides  a terminal  status 
service  call  which  allows  a user  orogram  to  test  whether 
input  data  is  available  for  oroeessina  fD.i).  This  function 
could  be  used  to  test  for  a break  kev  indication  Purina 
outout  by  the  user  program. 

Due  to  the  unavoidable  delays  in  user  program 
response  caused  by  swapping  and  aggravated  by  the  relatively 
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low  data  transfer  rate  of  the  mini-disk 


the  WTS  terminal 
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interface  was  designed  to  provide  character  echoino  and 
simole  line  editinq.  This  ensured  reasonable  response  t imes 
to  key  activation  bv  the  user,  even  though  his  nroaram  was 
not  currently  in  memory.  Each  character  kev  activated  at  a 
keyboard  results  in  the  appropriate  character  beina 
displayed  on  the  CRT  by  MTS.  The  line  editinq  features  are 
discussed  in  section  3 below. 

There  are  four  576  b y *■  e D M A terminal  buffer  areas 
located  in  R A M . Thus*  a 2 30  4 byte  area  of  toe  Sycor  uuo  ' s 
main  memory  has  been  allocated  by  the  system  hardware  design 
for  terminal  disolay  buffers.  To  take  maximum  advant-aoe  o f 
this  memory  utilization,  the  decision  was  made  to  use  this 
area  as  the  i n o u *■  holding  buffer  as  well  as  the  display 
buffer.  This  eliminated  the  need  for  additional  input 
buffers  and  the  extra  processing  time  required  to  mpyp  a 
completed  input  line  to  a separate  buffer. 

2.  Display  Description 

The  first  oU  disolay  character  positions  of  each 
terminal  are  physically  separated  from  the  re^aininn  5 l ? 
character  positions  bv  a blank  line.  This  led  to  the 
decision  to  reserve  the  first  line  for  display  of  status  and 
error  messages.  All  inout  and  output  of  data  was  to  be 
accomplished  in  the  remaining  512  character  positions. 
Thus,  each  ^76  byte  terminal  buffer  is  logically  divided 
into  two  separate  buffers,  as  follows: 
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STATUS  l I MF 


63! 


* / / / / / / / / / / * 

JO 

D 

63  ! 

J64 

I 

127  ! 

! 128 

B 

s 

i9i : 

J 1 92 

U 

P 

255  ! 

1256 

F 
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J 320 

F 

A 

383  ! 

J 384 

E 

Y 

447  J 

J 448 

R 
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The  numbers  are  decimal  and  specify  character  positions 
within  the  status  line  and  display  buffer. 

The  terminal  status  line  is  used  by  MTS  to  display 
three  types  of  status  i n f o r ma f > on : 

(1)  The  current  virtual  drive  and  floppy  d i s k assionments 
for  that  terminal. 

( 2 ) The  size  of  the  user's  swap  i m a a e , i.e.  the  amount  of 
memory  space  currently  available. 

(3)  Error  message  alerts  oroduced  bv  MJS  system  commands* 
or  resulting  from  user  proaram  calls  on  the  DISPLAY 
MSG  service  routine  (see  section  F . 2 of  Appendix  A). 

The  status  line  display  format  and  contents  are  discussed  in 
detail  in  section  E of  Appendix  A. 

As  indicated  by  the  above  format  description,  the 
display  buffer  can  hold  a maximum  of  512  characters  (fi  lines 
on  the  CRT).  As  previously  mentioned,  this  Duffer  not  only 
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provides  the  display  of  characters  hut  also  acts  as  an  inruf 
buffer,  holdina  the  input  data  until  the  user's  croqra'" 
requests  it.  Since  MTS  provides  simple  line  eaitino  of 
input  data,  this  data  can  not  be  ronsioerea  available  to  the 
user's  program  until  an  input  line  termination  character  has 
been  received  by  MTS.  To  establish  an  input  buffer  for  a 
program,  the  user  enters  the  data  and  terminates  the  lire  bv 
hitting  the  N F fl  1. 1 N E or  ENTER  keys  on  the  keyboard.  Tkis 
establishes  that  line  as  an  input  buffer  available  for 
processing  bv  the  user's  proqram.  Note  that  the  kev 
combinations  'I/O  CTL  M 1 or  'SHIFT  CR'  (on  the  number  pad) 
will  also  result  in  the  termination  of  an  input  lire. 
Either  of  these  keys,  as  well  as  NEWLINE  and  ENTER,  may  be 
used  f c r line  termination. 

Once  an  input  buffer  has  been  establisheo  t re  user 
may  continue  to  input  data  on  the  next  line.  The  user  mav 
use  any  of  the  line  eoitinq  or  other  cursor  control  features 
on  this  new  line  of  input  data.  However,  this  new  line  may 
not  bd  teroi rated  until  the  user's  program  has  processed  tnn 
previous  input  buffer  (see  terminal  alerts  below). 

Each  character  output  from  the  user's  program  is 
displayed  at  the  current  cursor  position.  Fach  output 
results  in  all  input  buffer  pointers  beina  reset  to  the 
character  position  at  the  end  of  the  output  data.  Thus, 
subseauent  I/O  will  start  at  this  Point.  This  implies  t‘,a*' 
if  the  user  had  been  in  the  middle  of  enterino  data  when  the 
output  occurred,  it  must  be  reentered. 

The  MTS  terminal  interface  nrovioes  the  user  with 
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either  a visual  or  auoio  resoonse  to  each  key  depression 


Normal  visual  resoonse  is  provided  by  display  of  the  entered 
character  (ec^oinn)  and/or  movement  of  the  display  cursor. 
The  display  cursor  is  a blinking  underscore  character  which 
marks  the  current  position  on  the  screen.  Data  is  always 
entered  and  displayed  at  the  current  cursor  position. 

The  audio  responses  consist  of  either  a beer  or 
click  at  the  terminal.  4 terminal  been  alert  will-  pe 
generated  for  any  of  the  follow  inn  conditions: 

(1)  An  input  buffer  is  waitina  to  be  processed  bv  trie 
user's  oroaram  and  the  terminal  user  attempts  to 
terminate  a n»w  input  line. 

(2)  An  attempt  is  made  to  move  the  cursor  back  oast  the 
start  of  the  current  line.  For  example,  attempting  to 
delete  the  previous  line  or  character  a*ti>r  trie  lino 
has  been  entered  by  a termination  key  will  result  in  a 
beep . 

The  terminal  click  alert  is  associated  with  the 
display  scrolling  feature.  Since  the  display  buffer  also 
acts  as  an  incut  buffer,  scrollina  the  display  when  the  SI? 
bvte  display  buffer  is  full  could  destroy  input  data  which 
has  not  yet  been  processed.  For  example,  the  user  could  be 
entering  a 512  character  string.  Uron  termination  of  that 
input  line.  MTS  will  prevent  scrollina  until  the  user's 
proaram  has  processed  the  first  6a  characters.  This  ensures 
that  the  input  data  is  not  destroyed  bv  the  scrolling 
operation.  This  scrolling  lockout  is  indicated  to  the  user 
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by  a terminal  click  alert 


5.  Terminal  Key  Functions 

The  terminal  kevs  fall  into  five  haste  functional 

groups : 

(1)  Character  string  keys  - these  are  the  alphanumeric  and 
special  character  kevs  normally  available  to  the  user 
for  input  of  data.  Alphabetic  characters  are  entered 
and  displayed  in  either  uooer  or  lower  case*  depend ino 
on  the  key  mode  (see  below).  Ihe  tao  Key  causes  the 
entry  and  display  of  a special  tab  character,  no 
blanks  are  oadded  in  for  tabs. 

(2)  Entry  mode  kevs  - these  keys  define  the  interpretation 
of  keys  for  special  functions  or  alphabetic  uorer 
case.  These  include  the  FUNCTION  SELECT,  I/U  CONTROL, 
and  SHIFT  keys.  In  addition,  the  key  combination 
FUNCTION  SELECT  and  C sets  or  clears  the  alphabetic 
key  entry  mode  to  uooer  or  lower  case.  This  functions 
as  a shift  key  lock  because  a physical  lock  is  not 
provided  with  the  terminal  kevboara. 

(3)  Line  termination  keys  - these  keys  define  the  termi- 

nation of  an  input  line  of  data.  Input  data  to  b ° 
processed  by  the  user’s  oroqram  must  be  terminated 
with  one  of  the  fo'lowino  keys  or  kev  combinations: 
NEWLINE?  ENTER?  I/O  CTL  M?  or  SHIF|  CR.  Their 

function  was  discussed  in  the  proceeding  section. 
Another  termination  key  is  EPRdR  RFSFT,  which 


specifies  that  the  input  line  it  terminates  is  to  be 
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processed  by  MTS  as  a system  command. 

(4)  Line  editing  and  cursor  control  keys  - these  keys 
provide  the  simple  line  editino  features  such  as  line 
delete  (NEXT  FM A T ) l character  delete  (RACKSPACF); 
clear  screen  (FS  $ or  I/O  CTL  $)»  and  move  cursor  left 
or  riaht  (<--  ? 

(5)  Number  pad  keys  - consists  of  10  numeric  dioits  ana 
ASCII  control  characters  located  on  the  richt  side  c4 
the  keyboard.  The  dipits  function  in  the  same  manner 
as  the  other  numeric  digits  on  the  Keyboard.  Tne 
ASCII  control  characters  are  displayed  when  the  S h T F T 
key  is  depressed  in  conjunction  with  the  appropriate 
key.  The  only  control  character  which  affects  the 
display  is  SHIFT  CK  (see  line  termination  keys). 

All  terminal  keys  and  their  functions  are  described  in  more 
detail  in  section  D.2  of  Apnendix  A. 

G.  CHOICE  OF  A PROGRAMMING  LANGUAGE 

Following  the  design  ohase»  it  was  necessary  to  choose 
an  appropriate  orogrammina  language  to  be  used  in  the 
implementation  chase  of  development.  An  obvious  reouirement 
was  that  the  language  selected  must  support  system 
programming  for  the  8080  m i c r on  roc e S s o r . Other  factors 

involved  in  choosing  a language  for  the  NTS  development 
included  the  followinq: 

(1)  Efficiency  of  the  code  generated  by  the  assembler  or 
compiler.  An  important  consideration  in  any  operating 
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system  development  is  minimizing  the  amount  of  memory 
and  processina  time  utilized  by  system  routines. 

(?)  Ease  of  access  to  machine  resources  (e.q.  registers! 
memory*  I/O  ports*  stack,  etc.)  through  the  constructs 
provided  by  the  1 anauaqe.  This  must  be  considered 
whenever  developing  software  which  will  be  interf aci na 
with  the  bare  machine. 

(3)  The  availability  of  the  assembler  or  compiler  tor 
development  work.  The  turn-around  time  for  assemhlv 
or  compile  tasks  and  the  debug  aids  orovidea  by  a 
1 anauaqe  are  important  factors. 

(4)  The  inclusion  in  the  lanquane  of  convenient  control 
structures  ana  s e 1 f -doc umen t a t i on  features  similar  to 

those  found  in  most  hiah-level  structured  lanauaqes. 

< 

It  has  been  sncwn  that  these  features  assist  in  rand 
system  develoo-ent  and  checkout*  s t r a i gh t to r wa r d 

maintenance  and  modification*  and  a highly  reliable 
system.  It  was  envisioned  that  MTS  would  be  enhanced 
and  modified  extensively  as  the  rpaui rement  for 
additional  microcomputer  development  facilities 

increased.  Thus*  ease  of  future  modification  and 
maintenance  was  a prime  consideration. 

(5)  The  ability  of  the  assembler  or  compiler  to  generate 
error  free  code  was  important  for  ease  of  coding, 
testing*  and  oebuagino  the  system  modules  during 
project  development. 
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There  were  three  languages  available  at  NPS  which 


supoorted  programming  for  the  8080  microprocessor.  Tne 

f 

followinq  is  a brief  description  of  these  lanauaors 
their  advantaoes  and  a i sadvant aqes  : 

( t ) 8080  Assembly  Lanouaqe  T 8 1 - the  assembly  lanquaqe 

developed  for  use  with  the  8080  microprocessor.  It 
satisfied  (1)  and  (?)  above  by  oroviuino  efficient  and 
direct  access  to  the  machine  resources.  Item  (3)  was 
satisfied  oecause  a resident  assembler  ana  dynamic 
aebuqoinq  tool  were  available  on  an  T NTtLLFC  6 /MOL)  80 
microcomputer  system  for  use  during  the  project 
development.  The  major  limitation  in  usinc  am 
assemblv  1 anguaoe  is  its  failure  to  satisfy  item  ( 4 1 . 
(2)  ML 80  (12)  - a structured  system  oroqrammino  1 anouaoe 

for  the  8080  microprocessor  developeo  as  a tkesis 
project  at  NPS.  It  is  composed  of  two  indenenaent 
languages:  M80  - a macro  oriented  1 anguaae!  and  L80  - 

a machine  oriented  lanquaqe.  It  incorporates  such 
features  as:  control  structures#  similar  to  those 

found  in  most  high-level  structured  lanauages?  allows 
full  use  and  control  of  the  resources  of  the  8080 
microprocessor  throuqh  the  use  of  alqebraic  notation 
for  mac h i ne- 1 e ve 1 register  and  data  operations: 
provides  compile-time  features#  such  as  expression 
evaluation,  ccnaitional  compilation#  and  macros?  and 
provides  load-time  facilities#  such  as  the  linxino  o* 
precompiled  procedures  into  the  object  program 
(generates  relocatable  code).  It  was  also  available 


S9 


as  a resident  compiler  on  the  I^TBLLtC  P/MOP  PO.  Thus 
to  some  degree*  MLPO  satisfied  all  the  considerat ions 
mentioned  above  except  (5).  That  is*  it  haa  never 

been  used  for  a large  system  development  ana  thus  its 
performance  in  that  environment  was  untested. 

(3)  PL/M  f91  - a high-level  orooramming  I annuaae  designed 
to  provide  system  prooramming  for  the  6080 
m i c r oo roc e sso r . Tt  was  desianed  to  facilitate  the  use 
of  modern  techniaues  in  structured  programmino.  Thus* 
it  came  the  closest  in  satisfyina  consideration  fa) 
above.  However*  its  major  disadvantaoe  was  in 
qeneratina  less  efficient  code  and  allcwino  1 055 

direct  access  to  the  machine  resources  than  the 
oreceedino  two  1 anquaaes. 

After  considering  the  advantaoes  ana  d i s ad  van t aoe s of 
the  1 anguaoes  available*  the  decision  was  made  to  utilize 

ML80  as  the  primary  development  lanouage  tor  t'TS.  A subtas< 

of  the  thesis  project  was  to  test  MLP0  as  a programmino 
language  in  a large  system  development  environment.  Results 
of  using  MLPO*  including  recommended  enhancements  to  t n® 
language  and  it's  facilities*  are  included  in  the  remaining 
chanters . 
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V 


MTS  IMPLEMENTATION 


A 


Top  down  svstem  design  and  ^odu' ar  programming  arp 
current  software  enaineerino  concepts  which  strongly 
influenced  the  design  and  implementation  of  VTS.  As  each 
specific  functional  requirement  of  a timeshared 
microcomputer  svstem  was  identified/  a new  module  was  added 
to  the  MTS  design  to  satisfy  the  reauirement.  An  effort  was 
made  to  make  each  logical  module  an  independent  entity 
communicating  with  other  svstem  modules  rhrough  a simple/ 
well-defined  interfacp.  This  samp  concent  was  also  applied 
to  the  implementation  phase  of  development.  Each  lonira! 
module  was  implemented  as  a separate  code  module  with  rnp 
fewest  possible  number  of  intermodule  linkages.  Five 
modules  were  needed  to  meet  the  processing  and  resource 
sharing  reguirements  imposed  by  timesharing.  Ir  addition  to 
these  code  modules/  a sixth  declaration  module  was  included 
to  define  the  underlying  data  structure. 

Use  of  MLPO  as  the  implementation  1 anauage  for  v T S 
affected  the  development  primarily  in  the  area  of  module  an  1 
data  structure  linkages.  The  problems  encountered  can  op 
attributed  mainly  to  the  limited  memory  size  ( 1 e>K ) of  the 
INTELLEC  P/MOD  P 0 which  hosted  »hp  **L  P 0 compiler.  Due  to  *•  r » 
relatively  small  amount  of  work  area  available/  many  of  ♦■re 
compiler's  tables  and  stacks  were  too  small  to  satisfy  tho 
. This  size  limitation  forced  a cor resrordi no 


demands  of  MTS 


limitation  on  the  size  of  individual  MTS  modules  and 
submodules.  The  effect  of  forcina  a decrease  in  the  natural 
size  of  the  MTS  proaram  modules  was  to  increase  the  linkaqe 
requirements  between  these  modules.  The  ML60  compiler 
provides  some  link  editina  facilities#  but  does  not 

conveniently  sunport  the  numerous  linking  requirements 
encountered  in  the  development  of  MTS. 

A.  SYSTEM  STATE  BLOCK 

The  management  functions  performed  by  ‘-US  may  be  divided 
into  task  management  and  resource  management.  Task 
management  is  concerned  with  the  control  and  record-keep i no 
functions  necessary  to  suooort  uo  to  four  concurrent  tasks. 
Resource  manaaement  provides  the  same  functions  for  t r.  e 
hardware  resources  of  t^e  Sycor  440.  noth  tyres  of 
management  involve  recording  status  information  for  later 
use  in  processing  control.  Considered  jointly#  this  status 
information  defines  the  state  of  the  M T S svstem  ana  forms 
the  basis  of  the  MTS  data  structure. 

In  the  implementation  of  MTS  it  was  found  necessary  to 
combine  all  status  information  into  a logical  and  physical 
block  called  the  system  state  block  CSSB).  This  approach 
was  originally  adopted  to  reduce  the  overhead  of  rne 
recovery  feature.  The  status  information  contained  in 
SSB  must  be  copied  to  a recovery  file  after  each  swap.  oy 
consolidating  this  data  into  a compact#  continuous  block, 
only  a single  mini-disk  access  was  required. 
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Subsequently*  it  was  found  desirable  to  combine  all 


variables  referenced  by  two  or  more  NTS  modules  into  a 
sinqle  declaration  mocule  with  olobal  scone.  This  improved 
the  readability  of  the  source  rroqram,  simplified  rrnqram 
debugging,  and  facilitated  maintenance  of  the  system.  Th  = 
SSti  is  logically  composed  of  three  distinct  elements: 

(1)  task  control  tahle  * contains  information  on  tne  state 
of  each  task  ana  data  required  to  suooort  swaomnq. 
Each  variable  contains  four  entries  - one  for  each  o * 
the  four  terminal  tasks. 

(2)  disk  mao  table  - contains  information  on  the  status* 
protection  attributes*  and  mini-oisk  location  o*  all 
virtual  f 1 oooy  disks.  Each  variable  contains  52 
entries  - one  for  each  of  the  32  possible  virtu a1 
f 1 oopy  d i s k s . 

13)  system  control  variables  - single  variables  referenced 
ov  several  modules*  e.o.  the  swao  lock  and  the  number 
of  the  task  currently  executing. 

Each  task  control  table  and  disk  map  table  entry  was 
actually  implemented  as  a named  bvte  vector  indexed  bv  the 
task  number. 

8.  MONITOR  MODULE 

The  monitor  module  i ncoroorates  all  of  the  task- 
management  functions  required  by  VTS  into  a physical lv  and 
logically  distinct  module.  Included  in  this  module  ar« 
routines  which  handle  the  loading  of  a task,  schedulino  a 
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task  for  execution,  swapping  tasks  between  mem iory  and  the 


mini-disk,  and  deleting  a task  after  an  if  recoverable 
hardware  error.  Du®  to  the  module  size  limitation  imposed 
bv  the  lbk  VL80  compiler,  it  was  necessary  to  Divide  the 
monitor  into  utility  and  task  "'anaae^ent  submodules  for 
compilation.  4 third  submodule,  containinq  the  initial 
proaram  load  routines,  was  included  in  the  physical  monit-cr 
module  for  reasons  o * convenience  rather  than  logical 
continuity. 


1.  Utility  Submocule 

It  was  found  convenient  in  the  implementation  of  *•'  T S 
to  develop  a qrouo  of  utility  routines  to  handle  recurring 
primitive  operations  required  to  access  entries  in  the 
system  state  block.  Since  "■ost  SSd  entries  are  inaexeo  p v 
either  a task  number  or  a virtual  disk  number,  a significant 
savings  in  memory  space  was  realized  by  replacing  in-line 
code  segments  with  calls  to  a utility  for  indexing 
operations.  The  convenience  of  having  these  primitives 
available  was  offset  somewhat  bv  the  necessity  to  compile 
the  utilities  submodule  independently  of  the  calling 
routines. 


2.  Task  Management  Submodule 

The  life  cycle  of  a task  in  a mu  1 t i o r oo r ammed 
environment  mav  be  represented  bv  a series  of  transitions 
between  process  states.  Tt  is  the  job  of  the  operating 
system  to  control  and  monitor  these  transitions  [10],  In 
the  MTS  operating  system  this  function  is  performed  by 
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the 


task  manaaement  submodule. 

Each  user  task  in  the  MTS  environment  may  exist  in 
one  of  the  fotloxina  states: 

(1)  logaed  in  - task  is  active  but  not  vet  loaded 
(?)  hold  - task  requires  the  services  of  the  terminal 
command  processor  to  alter  its  virtual  environment 

(3)  blocked  “ task  is  waitinq  for  the  completion  of  an  I / n 
OPerat i on 

(4)  ready  - task  is  waitinq  for  the  CPU  to  become 
a v a i 1 ab 1 e 

(5)  running  - task  has  been  allocated  both  memory  and  t n e 
CPU 

The  current  state  of  a task  is  determined  bv  the  bit  rat  tern 
set  in  the  status  byte  associated  with  that  task.  Each  bit 
of  this  status  bvte  corresponds  to  a different  process 
stater  and  there  is  a different  status  byte  associated  w i t 'n 
each  task.  Since  the  information  contained  in  the  task 
status  bytes  is  an  important  part  of  the  overall  svstem 
status#  they  are  located  in  the  system  state  block. 
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Note  that  the  task  status  byte  olays  three  different 
roles  in  the  iranaqenent  of  user  tasks: 

(1)  It  drives  the  ooeraMnn  of  the  monitor. 

( 2 ) It  provides  the  simplest  possible  interface  between 
the  monitor  and  the  terminal  command  processor.  The 
MfP  need  only  set  the  appropriate  bit  to  inform  tne 
monitor  that  a new  task  has  entereo  the  system. 

( 3 ) It  allows  the  terminal  interface  module  to  inform  tne 
monitor  that  a system  command  has  been  entered  without 
interruotina  the  current  task.  This  feature  was 
implemented  to  reduce  the  swapping  overhead  of  system 
command  processina  while  still  allowing  MCP  to  be  a 
swaopab 1 e task. 

Implicit  in  the  sequential  examination  of  bits  carried  out 
bv  the  monitor  is  a Hierarchy  of  process  states.  Since  both 
the  terminal  interface  module  and  the  MCP,  as  well  as  tho 
monitor  itself*  may  set  various  hits  in  the  status  cvte 
independently  of  each  other,  some  method  of  resolving 
conflicts  was  necessary. 

3.  Initial  Proaram  Load  Submodule 

While  not  logically  a part  of  the  task  management 
function,  the  IPL  submodule  has  an  important  influence  on 
the  operation  of  the  monitor  after  MTS  is  loaded.  The 
preceding  section  described  how  the  SS^,  particularly  t h® 
task  status  byte,  drives  the  operation  of  the  monitor.  Tne 
primary  task  of  the  IPL  submodule  is  loadino  values  into  the 
SSB  oefore  ^TS  is  executed.  Two  loadina  options  have  h«en 

bb 
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i mo  1 emen  t ed : 


initialization  and  recovery 


The  recovery  option  is  the  simplest  and  most 
st  rai qht  forward  of  the  two.  As  discussed  in  section  I V . R . 1 
the  four  swap  files  and  the  recovery  file  together  contain 
all  the  information  MTS  needs  to  recover  after  a system 
failure.  IPL  processino  is  limited  to  searchino  the  Sycor 
file  directory  for  the  recovery  file's  sector  address  an f 
then  readinq  the  file  into  the  SSB. 
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directory  for  each  virtual  flopoy  disk  file.  For  every  tile 
found  in  the  directory,  system  or  virtual  floocv  disk, 
beginning  and  endina  sector  numbers  must  be  recorded  in  tne 
TCT  and  DMT  respectively.  Initialization  of  the  D w T also 
requires  that  protection  kevs  and  attributes  mUst  oe  copied 
from  the  con f i gurat  i on  file. 

The  IPL  submodule  provides  the  only  internal 
interface  between  MTS  and  the  Svcor  orerat inq  system,  i.e. 
the  file  directory.  This  submodule  is  also  the  only 
routiner  other  than  the  timer  handler  in  the  interrupt 
module,  which  calls  the  monitor.  The  final  distinguishing 
feature  of  the  IPL  submodule  is  that  it  is  the  only  non- 
resident module  of  MTS.  Since  IPL  is  only  reaui red  once, 
immediately  after  mjs  is  loaded,  the  code  was  written  to  be 
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loaded  in  the  user  area  of  memory.  Once  normal 
Degi nsi  the  IPL  submodule  is  overlaved  by  the 
task  which  is  loaded. 


operat i on 
first  user 


INTERRUPT  MODULE 


The  Sycor  440  provides  a como rehens i ve  set  of 
prioritized  interrupts.  Each  hardware  interrupt  causes  the 
execution  of  an  8080  RESTART  1 (RST  1)  instruction.  This 
instruction  behaves  like  a ca'l  to  location  000PH.  That  is, 
it  results  in  the  procram  counter  value  heino  pushed  onto 
the  current  stack  and  control  heino  transferred  to  lncation 
000 Oh.  Due  to  this  hardware  characteristic,  user  proorars 
must  ensure  that  anv  user  defined  stacks  are  at  least  f^ur 
fcvtes  laraer  than  the  maximum  size  renui r«o  by  the  user's 
own  code.  This  will  ensure  that  the  stacus  will  not 
overflow  if  their  proaram  is  execution  when  an  interrupt  is 
gene  rat  ed . 

Since  all  interrupts  cause  execution  of  the  s a r e 
interrupt  instruction,  some  means  must  be  available  to 
determine  which  device  generated  the  interrupt.  The  Sycor 
440  solves  this  problem  bv  defining  an  interrupt  level  for 
each  different  device.  There  are  17  interrupt  levels  with 
values  ranaing  from  0 to  16.  The  priority  of  interrupts  is 
established  bv  assinning  a Maher  priority  to  a device  with 
a higher  numeric  value.  ,v  h e n an  interrupt  occurs  the  level 
used  to  identify  the  initiating  device  is  available  on  a 


specific  input  port 


Simultaneous  interrupts  will  be  placed 


on  the  interruot  input  port  in  a priority  sequence.  T h a t 

is#  the  levels  will  be  input  in  descending  sequence  by  level 
number.  When  the  level  on  the  incut  port  is  ?ero  *11 
pending  interrupts  have  been  processed.  The  interrupt  input 
port  number  and  the  interruot  level  assignments  which  apply 
to  the  Current  N P S Sycor  4 £10  hardware  configuration  a r 
contained  in  Ref.  1. 

The  interrupt  module  processes  two  basic  interrupt 
cat  ego  r i e s : 

(1)  timer  interruot  - this  interrupt  is  aenerated  tv  an 
internal  clock  once  ev*»rv  50, ns,  w n e n it  has  ij»en 
enabled.  This  provides  MTS  with  t n e c a p a b i ! i t v o * 
accomplishing  tasks  which  must  be  gone  on  a periodic 
basis.  It  also  provides  MTS  with  the  m = a n s for 
regaining  control  of  the  system  from  a user  program. 

(21  device  interrupts  - these  interrupts  are  aenerateri  bv 
a specific  peripheral  device  to  indicate  the 
completion  of  a task  or  a request  for  service.  Tn» 
processino  of  these  interrupts  is  device  dependent. 


1 . Data  St  ructures 

The  interruot  module  consists  of  two  parts#  an 
interrupt  controller  and  a set  of  interrupt  handlers.  Ther° 
is  an  interruot  handling  routine  for  each  interrupt  level 
processed  bv  MTS.  The  data  structures  required  cv  tno 
interruot  module  include: 

(11  interruot  st act  - a 3h  byte  data  vector  used  to  sav» 
the  current  system  environment  prior  to  any  interrupt 
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processing  and  to  restore  the  environment  uron 
completion  of  interrupt  processina. 

(2)  blink  timer  - a single  byte  used  to  S^ore  the  current 
value  of  the  periodic  terminal  processing  counter. 
This  counter  is  decremented  once  every  Sums  and  is 
used  to  determine  when  to  blink  t^e  cursor  character 
at  each  terminal. 

(3)  task  timer  - a qlobal  system  variable  used  to  control 
a user  task's  timeslice. 

( 4 ) lock  - a qlobal  system  variable  used  to  iroicate 
swappina  lockout. 

2.  Interrupt  Processing 

During  WTS  initialization*  locations  OQOft-Qho/'li  are 
loaded  with  a jump  instruction  to  the  interrupt  controller. 
Thus*  when  an  interrupt  occurs*  the  interrupt  controller  is 
called.  It  saves  the  current  environment,  identifies  toe 
interrupt  level  and  calls  the  appropriate  handler  routine. 
Uoon  return  from  the  interrupt  handler,  the  controller 
checks  the  interrupt  input  port  to  determine  if  any  more 
interrupts  are  oendina.  If  so*  the  seouence  is  rereateg; 
otherwise  the  environment  is  restored*  interrupts  enabled, 
and  control  returned  to  the  interrupted  process. 

The  interrupt  handlers  oroviae  the  following 
process i nq : 

(1)  timer  handler  - manages  the  two  functions  of  ^ T S which 
occur  at  oeriodic  intervals.  These  are  blink i. in  t h ® 
terminal  cursors  and  returning  control  to  the  system 
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D.  SERVICE  MODULE 


The  most  visible  coint  of  contact  between  MTS  and  user 
proarams  is  the  software  interface  which  multiplexes  the 
hardware  resources  of  the  Sycor  4 a 0 . In  the  implementation 
of  MTS  all  those  procedures  and  routines  which  provide  this 
resource  manaaement  were  consolidated  into  a s inale  code 
segment  called  the  service  module.  Once  again,  aue  to  tne 
module  size  limitation  imoosed  bv  the  ML60  comoiler,  it  was 
necessary  to  divide  the  service  module  into  three  physical 
suomodu 1 es . 

1.  User  Interface  Submodule 

Section  IV. D describes  in  detail  •’he  form  o*  a call 
to  the  MTS  service  module.  The  implementation  of  this 
callinq  orotocal  follows  the  PL/M  convention  for  parameter 
passing.  That  is,  the  function  identifier  (a  single  b v t e ) is 
oassed  in  register  C,  while  the  oarameter  list  address  is 
oassed  in  register  oai r DE.  The  service  module  subseouentlv 
uses  the  A reqister  to  pass  the  return  value  back  to  Mip 
calling  proaram.  A user  program  accesses  the  service  module 
bv  loading  the  C,D,  and  E reoisters  with  the  aporopriate 
values  and  then  executing  a call  to  location  2000H. 

The  service  module  Drovides  an  alternate  entry  point 
for  service  requests  from  other  MTS  routines.  This 
alternate  entry  ooint  was  found  necessary  in  order  to 
implement  the  MCP  as  a swanpadl e imaae.  Since  a second 
entry  point  was  reouired,  it  was  decioeo  to  make  th« 
interface  as  genera)  as  nossible  bv  usina  neaative  function 
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identifiers  for  internal  service  calls.  This  maa*  ir 
relatively  s i mo  1 e to  verify  the  source  of  the  service 
request ( and,  as  an  added  benefit*  made  availaOle  an  entire 
new  series  of  function  identifiers  without  disruotinn  the 
series  already  in  use  for  external  calls. 

The  first  action  taken  by  the  interface  submodule 
unon  entry  is  settina  the  software  lock  which  suppresses 
swapDinq.  The  routine  continues  with  validation  of  the 
function  identifier  and  a call  to  one  of  the  other 
submodules  to  handle  the  operation  requested.  When  control 
is  regained  by  the  interface  submodule  the  swap  lock  is 
reset  and  control  returned  to  the  cal  lino  routine. 

2.  Service  Call  Submodule 

The  first  stec  in  the  implementation  of  the  virtual 
I/O  functions  was  to  determine  the  operations  performed  tv 
each  device.  Since  it  had  already  been  decided  to  limit  the 
scooe  of  this  baseline  system,  only  three  aevices  were 
considered:  terminals,  the  printer,  and  virtual  floopv 
disks  sharing  the  mini-disk.  A total  of  ten  operations  were 
identified  as  necessary  to  provide  virtual  I/O  with  these 
three  devices.  Subsequent  efforts  concentrated  on  the 
terminals  and  virtual  floppy  disks.  Data  structures  were 
developed  to  support  each  device  and  routines  written  tr 
simulate  the  operations  performed  bv  each.  To  conform  with 
the  modular  approach  adopted  for  this  oroj°ct,  the  terminal 
routines  were  incorporated  in  the  terminal  interface  module. 
The  service  call  submodule  contains  the  remainina  routines. 
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Appendix  A contains  a detailed  description  of  each  service 


call. 

3.  System  Call  Submodule 

MTS  was  designed  to  allow  each  user  a certain  amount 
of  flexibility  in  the  virtual  env i ronment  provided  bv  the 
system.  In  order  to  implement  this  feature  it  was  necessary 
to  orovide  additional  service  routines  to  handle  this  higher 
level  resource  manaoement.  These  additional  routines# 
called  system  calls#  are  utilized  by  the  M C H to  satisfy 
terminal  reauests  for  changes  in  a user's  environment.  It 
was  decided  that  these  same  services  should  also  be  provided 
to  user  programs.  This  led  to  the  inclusion  of  system  c a U s 
in  the  service  module. 

The  system  calls  affect  changes  in  a user's  virtual 
environment  by  acting  directly  on  the  status  variables 
contained  in  the  S S P . Normally,  two  or  more  Parameters  are 
reguired  to  soecify  exactly  the  action  desired.  bach 
parameter  is  examined  closely  bv  one  of  several  validation 
procedures  contained  in  the  system  call  submodule.  Cverv 
effort  is  made  to  ensure  that  the  reguest  is  compatible  with 
the  current  system  state  before  any  changes  are  made  in  the 
SSB. 


E.  MTS  COMMAND  PROCESSOR  MODULE 
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The  MTS  command  processor  (MCP)  was  desianed  to  be  a 
completely  independent  module  of  T S (see  IV.E.l).  Ton 
decision  was  made  to  implement  MCP  utilizing  a high-level 
lanquage?  namely  PL/M.  This  approach  had  the  followino 
advantages: 

(1)  Use  of  the  PL/M  structured  constructs?  debugning  and 
se 1 f -doc umen t i nc  facilities  to  assist  in  the  raoid 
development?  checkout  and  integration  of  the  command 
processor. 

(?)  Assistance  in  simolifvinq  future  maintenance  and  modi- 
fication tasks  associated  with  the  command  processor. 

( 5 ) Provided  a PL/M  prooram  which  illustrates  and  tests 
the  system  and  service  call  interface  reouiremer,  f s o 4 
a program  with  mt$. 

Since  the  MCP  interface  did  not  reauire  direct  access  to 
the  machine  resources?  the  inefficiency  of  code  generation 
resulting  from  the  use  of  a hiqh-level  1 anauage  was 
outweiqhed  by  the  advantaaes  it  provided. 

1.  Data  Structures 

The  data  structures  required  for  a comrand  processor 
are  fairly  common?  decendino  on  the  number  and  complexity  of 
commands  available  to  the  user.  Those  used  Ev  vcp  include: 
a 64  byte  command  buffer!  a command  buffer  pointer  to  too 
next  character;  lenoth  of  the  input  command  seauence?  a bvt“ 
vector  to  hold  and  transfer  the  command  parameters  to  the 
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service  modu 1 e . 

The  MJS/MCP  interface  is  through  the  internal 
interface  oort  located  at  1F00H.  The  aata  structures 
required  to  generate  the  function  call  interface  are 
identical  to  those  used  bv  CP/W  f4l.  An  example  o*  the 
calling  procedures  can  be  found  in  section  F.a  of  Appendix 
A.  MCP  is  also  required  to  save  the  l»TS  svster  stack 
pointer  prior  to  orocessing  the  command.  To  maintain  its 
i naeoendenc e » MCP  utilizes  its  own  stack  for  internal 
processing.  It  then  restores  the  system  stack  oointer  nricr 
to  exit.  This  ensures  a proper  return  to  the  location  in 
the  MTS  monitor  where  MCP  was  initially  called. 

2.  Command  Processing 

The  command  processor  is  called  ov  the  MTS  monitor 
to  process  a system  command  entered  hy  the  terminal  user. 
After  savina  the  {ystem  stack  pointer  and  setting  uo  its  own 
stack*  the  data  structures  are  initialized.  The  svste" 
command  is  then  read  into  the  command  buffer  using  a 
sequence  of  MTS  service  calls.  If  the  command  buffer  is 
empty*  no  further  processina  is  accomplished,  MCP  returns  to 
the  monitor.  Assuming  there  is  a command  to  process*  the 
first  non-blank  character  of  the  command  is  read.  All  other 
characters  in  the  command  name  are  iqnorea  bv  MCP  since  the 
first  character  of  each  command  is  uninue.  If  the  first 


character  is  not  one 

o f 

the 

valid 

system 

commands  * 

an 

IMi/ALID  CMD  messaae  is 

sent 

t 0 

the 

se  r v i ce 

modu 1 e 

for 

display  on  the  appropriate  terminal's  status  line.  If  it  is 
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a valid  command  character* 


processing  of  the 


command 


sequence  continues. 

Each  command  is  processed  by  its  own  subroutine. 
Validation  of  the  parameter  seauence  and  svnta*  is 
accomolished  for  each  input  command  (see  D.3,  Appendix  A). 
An  INVALID  CMD  error  messaae  is  displayed  for  any  detected 
error  in  syntax.  The  followinq  conversions  of  innut 
parameter  values  are  performed: 

(1)  drive  letter  - ranqe  of  values  is  A-H;  the  ASCII 
letter  character  is  converted  to  a binary  number 
between  0 and  7 (e.o.  A = 0,  R=l*  etc.). 

(2)  disk  numoer  - since  the  ranoe  of  values  is  from  h-31* 
no  more  than  two  characters  mav  be  entered  tor  t h i s 
parameter;  the  input  ASCII  numeric  characters  ar° 
converted  to  the  equivalent  binary  value. 

(3)  memorv  size  - ranae  of  values  is  0-48*  thus  un  *■  o t «o 
ASCII  numeric  characters  are  converted  to  tn« 
eauivalent  binary  value. 

As  the  parameters  are  processed*  each  is  saved  in 
the  parameter  vector.  After  the  command  seouence  has  been 
interpreted*  MCP  calls  the  MTS  service  module  to  continue 
processing  the  command  request.  This  call  includes  the 
appropriate  system  command  number  and  the  parameter  or  1 i s' 
of  parameters  required  bv  the  syntax  of  the  command.  The 
MTS  service  module  will  always  return  a completion  code  to 
the  calling  routine.  VCP  is  implemented  to  immediately 
return  this  completion  code  to  the  service  module  in  the 
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form  of  a DISPLAY  MSG  system  call.  This  results  in  tn<? 
aoDrocri ate  messaae  heinn  disolayed  to  the  user  uoon 
comoletion  of  command  processinn  (see  E . '5 , Appendix  A).  MCP 
then  restores  the  system  stack  and  returns  control  to  the 
Vt  T S monitor. 

F.  TERMINAL  INTERFACE  MODULE 

The  terminal  interface  module  was  designed  and 
implemented  to  provide  all  functions  and  facilities  required 
to  interface  the  four  Svcor  4 A 0 disolay  terminals  with  the 
remainder  of  mis.  It  isolates  all  the  terminal  functions 
and  data  structures  irto  one  independent  module.  There  a re 
no  external  routines  accessed  and  only  two  v T ? ol oca i data 
structures  accessed  ov  th»  terminal  moonl  °.  Tnis  provides  a 
high  degree  of  mooule  indeoendence  and  minimizes  too 
external  linkage  reau i remen t s . 

The  terminal  interface  module  Drovioes  three  General 
services  for  the  Svcor  y 4 0 / m T S environment: 

(1)  terminal  primitive  functions  - Trese  are  functions 
which  are  commonly  provided  by  the  terminal  hardware 
of  intelligent  text  disolay  devices.  However,  the 
Sycor  440  reauires  that  they  be  provided  by  the 
software.  These  include  such  tasks  as  converting  from 
a keyboard  matrix  code  to  ASCII  code  for  incut  dafa, 
blinking  and  uodatinq  the  Current  position  indicator 
(cursor) , and  scrolling  the  disolay. 

(2)  input  key  processing  - this  is  processing  done  under 
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interrupt  control/  for  each  key  activation  interrupt 
received.  It  includes  chec*ina  for  c an  i t a 1 i 7.  a t i on  of 
alphabetic  character,  checking  for  any  special  v T S 
command  keys  and  input  character  ec^oina. 

(3)  system  interface  functions  - these  functions  provide 
the  primary  interface  point  between  th°  terminal 
module  and  other  MTS  modules.  F^ey  provide  rhe 
processino  of  reouests  from  ‘/TS  routines  for  terrinal 
I/O  or  status  information. 

The  terminal  interface  module  was  looicallv  and 
physically  divided  into  five  f 5 ) submodules.  Each  submenu le 
contains  the  linkage  and  macro  definitions  necessary  to 
interface  with  other  terminal  submodules  and  olofcal  system 
data  structures  as  reauired.  The  oassina  of  parameters 
between  procedures  and  submodules  within  the  terminal  moo win 
is  accomplished  entirely  through  th»  macninp  registers.  T n e 
terminal  interface  submodules  are  discussed  in  t h p f o 1 1 n * i n -> 
paragraphs . 

1.  Data  Structures 

This  submodule  provides  all  tKe  internal  data 
structures  used  by  the  terminal  interface  routines.  An 
important  point  to  keep  in  mind  is  that  all  data  structures 
providing  display  I/O  control  are  in  multiples  of  four, 
reguiring  one  for  each  of  the  four  terminals.  Tach  terminal 
was  assigned  an  identification  number  from  0-3. 

The  primary  data  structures  orovigina  display  T / 0 
control  include  the  four  S 7 6 byte  Dw  A buffers  discussed  in 
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section  I V . F . 2 and  the  followina: 

(1)  disolay  base  - a data  vector  co^tsininq  tne  base 
address  of  each  of  the  512  bvte  display  buffers  tones 
not  include  the  64  byte  status  1 irp). 

(2)  cursor  - a pointer  specifying  the  current  display 
address  (from  0-511)  ar  which  the  cursor  Character  is 
to  be  displayed. 

(3)  current  line  - a pointer  specify  inn  the  initial 
display  address  of  the  current  lire  in  . h i c c t *■  e user 
is  enteri na  data.  This  line  has  not  yet  teen 
terminated  by  a line  termination  key  (see  section 
I V . F . 2 ) . 

(4)  next  char  - a pointer  soecifyina  the  initial  disci av 
address  containing  the  next  character  in  the  incus 
line  (buffer)  to  be  processed.  fin  incut  line  i c 
aefineo  as  a strino  of  up  to  512  ASCII  characters 
which  has  been  terminated  Oy  a line  termination  key. 

(5)  end  ibuff  - eng  of  the  inout  buffer;  points  tc  tre 
display  address  where  a line  termination  key  -as 
received. 

(6)  terminal  status  - contains  the  current  status  o * each 
terminal's  inout  buffer)  the  possible  values  are  input 
waiting,  MTS  cmcj  ready,  or  ibuff  errrty. 

Additional  data  structures  include;  a matrix  coop 
to  ASCII  conversion  table;  an  uorer  or  Uwer  case  kev  entry 
mode  indicator;  status  line  base  address  vector;  and  data 


vectors  containing  status  line  messages 
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2 . Utility  Rout ines 

This  submodule  contains  the  basic  utility  routines 
which  provide  common  register  manipulation  ana  processing 
required  by  the  remaining  terminal  submodules.  The  only 
data  structure  needed  by  this  submodule  is  a swap  position 
address  used  for  swap  cursor  processing.  These  utility 
functions  include!  comoarino  display  pointers  to  determine 
if  they  are  equal!  converting  a binary  number  to  an  *SriT 
display  code!  qettina  and  storing  disola.  characters!  moving 
bytes  of  data  from  a memory  sourc°  to  a "emory  Destination! 
anq  swapping  the  current  cursor  positin'"  character  with  the 
swap  position  character.  This  is  the  basic  mechanism  used 
to  provide  the  blinkinq  cursor  feature. 

3.  Terminal  Interface  Primitives 

This  submodule  contains  the  routines  which  provioe 
the  primitive  functions  of  the  terminal  rnoaule.  These 
procedures  reauire  linkages  to  all  the  display  control  nata 
structures  and  the  status  base  ado-ess  vector.  The 

primitive  functions  include!  blankino  a specified  area  in 
the  display  buffer!  retrieving  aoprooriate  oisrlay  buffer 
and  status  line  addresses!  returning  the  current  terminal 
status!  sending  beep  and  click  alerts  to  t ° r m i n a 1 s ! 
scrolling  a specified  terminal's  display!  ang  uphat i-a  the 


current  cursor  position 


4.  Key  Processina  Routines 

This  submodule  provides  one  of  the  basic  functions 
of  the  terminal  module,  that  of  rrocessina  each  trey 
character  entered  at  a terminal.  It  reauires  linkage  to 

most  of  the  terminal  data  structures  and  to  one  alohal 
system  data  structure!  the  task  status  contained  in  the  SSb. 
A bit  is  set  in  the  task  status  byte  when  an  h'TS  system 
command  is  “ n t e r e d at  a terminal.  This  submodule  is  called 
by  the  terminal  interrupt  handler  to  process  the  input  'ey 
code.  The  followino  is  a summary  c * the  procession 
accomplished:  convert i no  the  input  matrix  code  t n t r ° 

appropriate  ASCII  code;  checking  for  and  converting  lower  to 
upper  case  letters  if  renui red!  checking  for  any  t e v 
commands  (includina  all  line  editino);  if  not  a key 

command*  the  input  Character  is  echoed  peck  to  the  terminal 
display.  A key  command  is  one  of  the  fol’cwina: 

(1)  line  termination  key  - either  an  t'ROR  RESET  or  CR 
key.  Checks  to  see  if  input  can  be  accented.  It 
input  is  already  waitinq  to  be  processed  t np 
termination  key  is  not  accepted  and  a terminal  beeo 
alert  is  sent  to  the  terminal.  Otherwise  the  current 
line  is  established  as  the  new  input  buffer.  the 
appropriate  terminal  status  is  set  and  if  it  is  an  ’•* T S 
command*  the  VCP  hit  in  the  task  status  bvt»  is  set. 
This  ensures  that  tKe  command  processor  is  called  c v 
the  monitor  to  process  this  commano. 

(?)  line  editino  and  cursor  control  kevs  - nroviges  *n» 


processina  for 


character 


delete,  line  delete*  cl»jr 


screen*  and  move  cursor  left  or  right.  Terminal  been 
alerts  are  oenerated  if  the  function  can  net  t° 
pe  r f o rmed . 

(3)  entry  mode  kev  - sets  or  clears  the  current  alrtdt'PMc 
key  entry  to  the  appropriate  uooer  or  lower  case  mode. 

5.  System  Interface  Functions 

This  submodule  contains  the  routines  which  provide 
the  terminal  module  interface  with  the  rest  of  the  'v  T S 
modules.  It  provides  readinq  and  writina  o*  characters  f 'ot 
or  to  the  terminal  display  buffers?  terminal  sfatqs 
information  (e.o.  whether  or  not  there  is  input  w a i t i n n ) ; 
display  of  status  and  MTS  messages  on  the  terminal  status 
line?  control  of  the  periodic  blinkina  of  the  display  cursor 
character?  ana  clearinq  the  status  line  when  r e a u e s t e a . 
This  submodule  links  to  the  terminal  data  structures  ano  to 
a global  system  variable  which  alwavs  specifies  the  terminal 
number  associated  with  the  function  request. 
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CONCLUSIONS  ANO  RECUWN'E'-OATIONS 


The  primary  goal  of  this  thesis  project  was  to  determine 
the  most  feasible  method  of  intearating  t h e Svcor  4 4 o system 
into  the  facilities  of  the  NPS  m i c roccipu t e r laboratory. 
The  aim  was  to  make  available  the  resources  of  the  Sycor  4 4 h 
in  support  of  microcomputer  systems  aeveiopment.  The  main 
objective  was  to  provide  an  environment  for  the  sharing  c* 
these  resources  among  multiple  users.  The  Microcomputer 
Timeshared  Svstem  was  developed  to  accomplish  this  resource 
sharing.  The  sharing  of  the  ”0*0  microprocessor  through 
multiorogrammina  rather  than  multiprocessing;  was  implemented 
only  because  of  the  hardware  configuration  of  the  'year 
4 4 0 . The  relatively  low  cost  of  microprocessors  would 
normally  lead  to  the  implementation  of  a m i c roo r oc e s sc r - 
based  timeshared  system  with  dedicated  CPUs  for  each  user. 
Thus*  the  emphasis  was  placed  on  the  sharing;  reoui  reirprt  s of 
the  remainina  system  resources.  The  shari nq  of  the  S / c o r 
4 4 0 memory  was  implemented  throuah  the  use  of  swacoino, 
providing  up  to  48K  of  RAM  for  user  programs.  Shan  na  of 
the  mini-disk  auxiliary  storaqe  was  provided  throuah  tn» 
virtual  f 1 oppv  disk  concent. 

Durino  the  research  and  development  of  MTS*  several 
areas  were  identified  as  potential  canoiaates  for 
enhancement.  These  areas  incluae:  enhancements  to  the 
prototype  MTS  system,  enhancements  to  the  Svcor  4 4 0 
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hardware,  and  MLfiO  enhancrrrents 


The  baseline  timeshared  system  as  implemented  provides 
sharing  of  the  Syc.or  '440  memory  and  mini-disk  resources 
amonqst  multiple  terminal  users.  An  obvious  extension  to 
this  basic  i mo  1 emen t a t i on  is  the  sharing  of  the  remaining 
dedicated  I/O  devices  (e.g.  printer,  cassette,  »tc . ) 
provided  bv  the  Sycor  440.  these  facilities  were  planned 
for  during  the  desian  phase  of  VTS  ana  interface  points 
provided  throuahout  the  implemented  oaseline  system  to 
ensure  easy  inclusion  at  some  later  date.  Additional 
information  on  sucaested  desian  and  implementation 
aooroaches  for  these  features  are  contained  in  . 1. 

From  the  Sycor  4 4 0/ w T S interface  point  of  view,  the  main 
enhancement  to  the  current  hardware  configuration  would  o e 
the  inclusion  of  the  *a st,  multi-sector  "i ni -rii sk  controller 
presently  under  development  at  Sycor.  To  assist  in  toe 
further  integration  of  the  Sycor  440  into  the  current 
microcomputer  development  facilities,  the  addition  o<  a 
floppy  disk  drive  would  be  helpful.  If  is  recommended, 
however,  that  the  floopy  disk  interface  be  an  addition  to, 
not  a replacement  for,  the  current  cassette  interface.  The 
cassette  driver  is  necessary  in  order  to  maintain 

compatibility  between  the  Svcor  440  and  the  340  dehuoaer. 
Additional  hardware  enhancements  which  would  assist  in 
implement i or  of  a timeshaned  microcomputer  system  include  a 
bounds  register  for  memory  protection  and  a mode  reaishen 
with  interrupt  looic  to  provide  a dual-state  machine. 

A secondary  objective  of  this  thesis  project  was  to 
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evaluate  the  performance  of  ML80  in  the  development  of  a 


reasonably  laroe  system.  In  oeneral  ( the  use  of  Ml. oh 
provided  many  advantaces  over  assembly  1 anquane  programming 
without  incurring  the  penalty  of  inefficient  cod*1 
generation.  The  alaebraic  notation  provided  by  the  lanouaqe 
proved  especially  convenient  in  workinq  at  the  register 
level.  The  improved  readability  of  the  source  code  was  o * 
great  assistance  durinq  the  development  of  v T S . The  other 
features  of  M L 8 0 discussed  in  section  I V . (1  o r o v e d / for  rh» 
most  oart ( to  be  very  satisfactory.  however,  as  described 
in  charter  V,  the  relatively  small  amount  of  ronorv 
available  on  the  system  which  hosted  the  compiler  caused 
numerous  problems.  To  provide  a completely  adeauatn 
environment  for  the  development  of  larger  system  s , a 
necessary  improvement  would  be  toe  modification  of  Ml. b 0 to 
run  on  a system  with  more  memory  available  for  tables  and 
stacks.  An  obvious  method  of  imolementina  this  imorovement 
is  to  enlarge  ML80 ' s fixed  size  stacks  and  run  the  compiler 
under  the  version  of  CP/M  modified  for  the  Sycor  a q 0 / *•'  T 3 
environment.  Additional  suogestions  for  enhancements  to 
MI.80  include:  addinq  a macro  library  capability  for  ease  of 
implementing  common  macros/  modifyinc  EXTERNAL  and  COMMON 
declarations  to  provide  linkaae  to  individual  identifiers 
rather  than  entire  modules  as  is  now  done/  and  outnuf tina 


table  listings  to  a print 


file  for  easier  debugging 


APPENDIX  A 


MTS  USER'S  MANUAL 


The  puroose  of  this  document  is  to  provide  the  user  with 
the  information  necessary  to  utilize  the  ^icrocnrouter 
Timeshared  System  (MTS).  The  contents  include  information  on 
settinq  up  the  Svcor  4 4 0 System  for  use  with  MTS,  loadinq 
and  initializino  v 7 g , and  ioterfacinq  with  the  MTS  operatim 
system.  Sections  A and  B provide  a qeneral  description  o' 
MTS  desiqn  concepts  and  the  Sycor  4 4 0 System.  Section  C 
provides  the  detailed  information  necessary  to  intenface  *■  n ® 
Svcor  440  System  and  mjs.  Section  D contains  information  on 
the  terminal  desian,  key  functions,  and  system  commands 
which  enable  the  terminal  user  to  communicate  with  ‘ 1 T 3 . 
Section  E describes  the  MTS  status  line  display  and  define  $ 
the  various  messaoes  displayed  by  MTS.  Section  F details 
the  services  provided  a user  oroaram  by  w TS , and  tne 
limitations  on  a user  orooram  runninq  in  the  MTS 
environment.  For  more  detailed  information  on  operation 
procedures  for  the  Sycor  440  System  consult  section  G,  Ref. 
2.  The  complete  MTS  desiqn  specification  and  implementation 
information  is  contained  in  Ref.  1. 
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A.  MTS  CONCEPTS  AND  DEFINITIONS 

The  acquisition  of  the  Sycor  440  Clustered  Terminal 
Processi no  System  provided  an  opportunity  for  development  of 
a shared  environment  for  microcomputer  research  and 
development.  In  response^  the  Microcomputer  Timeshared 
System  (MTS)  was  desioned  and  built  to  provide  the  basic 
machine  interface  and  system  manaaement  functions  necessary 
for  a scared  environment. 

The  purpose  of  M T S is  to  provide  an  interface  between 
the  bare  Sycor  400  machine  and  up  to  four  user  tas<s 
executinq  concurrently.  The  MJS  environment,  as  viewed  bv 
the  user,  provides  all  the  m i c r op r oc e s so r facilities 
required  for  m i c r oc omou t e r research  ana  development.  From  a 
svstem  point  of  view,  mts  »anaaes  the  available  hardware  to 
ensure  that  the  hardware  resources  are  equitablv  and 
efficiently  allocated  to  competinq  user  oroqrams.  MTS  is 
desiqned  to  interface  with  a version  of  CP/m  modified  to  run 
on  the  Sycor  440.  This  enables  all  systems  and  oronrams 
designed  to  run  with  the  CP/M  ooeratinq  svstem  to  run  on  the 
Sycor  440  with  minor  modifications  (such  as  a chanqe  in  load 
address).  This  includes  all  the  development  facilities 
available  with  CP/M,  such  as  the  context  editor,  dynamic 
debuqaer,  assembler,  etc.  Reference  1 contains  a list  of 
references  for  CP/M  and  its  facilities. 
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B.  SYCOR  440  HARDWARE  description 


The  Sycor  440  Clustered  Terminal  Process!  nq  System  at 
if  P S is  composed  of  a control  unit  containina  a cassette  tape 
drive*  four  disolay  terminals*  a Centronix  matrix  nrintor, 
and  a Svcor  Model  340  Communications  Terminal. 

The  control  unit  is  the  heart  of  the  400  system. 
Contained  within  a waist-hiah  cabinet  are  randt.  and  control 
logic  includinq  two  8080  chips*  64  K of  random  access  memory 
(RAM),  interfaces  for  all  oerinneral  devices,  a five 
megabyte  fixed  disk,  as  well  as  the  aforementioned  cassette 
t ape  drive. 

Located  together  on  the  front  of  the  control  unit  are  an 
QN/0FF /RESET  keylock  and  system  status  panel.  Turn i no  t h ° 
keylock  to  the  RFSET  position  activates  a diagnostic 
bootstrap  program  located  in  r®ad-on!y  memory  (ROM).  Tkis 
bootstrap  prooram  performs  several  diagnostic  tests  on  the 
CPU,  memory,  and  system  load  device  (cassette  or  mini-disk) 
and  then  initiates  system  loading.  Ihe  status  of  the 
diagnostic  tests  is  indicated  bv  a series  of  red  lights  on 
the  system  status  panel.  These  lights  are  turned  off  in 
sequence  as  each  phase  of  the  test  is  successfully 
completed.  When  all  red  lights  have  been  turned  off,  three 
green  lights  on  the  panel  will  remain  lit  to  indicate  that 
all  power  supplies  are  functioning  normally.  There  is  also 
one  additional  red  light  at  the  bottom  of  the  system  status 
panel  which  only  comes  on  if  the  temperature  inside  the 
control  unit  cabinet  exceeds  normal  operating  limits. 
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One  of  the  two  B0P  0 Chios  located  in  the  yaO  control 
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unit  serves  as  the  system  CPU.  The  8 0 8 0 instruction  set 
consists  of  the  7 B data  transfer,  arithmetic,  logical, 
branch,  stack,  I/O,  and  machine  control  instructions 
described  in  Ref.  3.  The  Svcor  840  provides  a comprehensive 
set  of  prioritized  interrupts  includino  a timer,  peripheral 
device,  and  auxiliary  storage  device  interrupts.  passina 
control  information  and  data  between  the  r0  8q  CPU  and 
peripheral  devices  is  accomplished  by  utilizino  the  T/P 
ports  (called  latches  in  Sycor  literature!  provided  on  *•  n e 
8080  chip. 

The  second  8080  chip  found  in  the  control  unit  acts  as  a 
controller  for  the  mini-disk.  The  r"  i n i - g i s k is  a single 
platter,  movable  head,  fixed  disk  blockea  into  SI?  Pvt® 
sectors.  There  are  800  tracks  on  the  disk  with  13  setters 
per  track.  Data  transfer  between  RAM  and  the  mini-aisk  is 
via  direct  memory  access  (DMA).  The  mini-disk  controller 
communicates  with  the  host  8080  CPU  throuah  a 13  bvte  disk 
control  block  (DC8)  located  at  a fixed  location  in  memor/. 

Peripherals  supported  bv  the  Sycor  yyQ  system  include 
bisynchronous  and  asynchronous  communication  devices,  up  to 
eight  display  terminals,  serial  and  line  printers,  and  card 
readers.  The  NPS  conf i aurat i on  has  four  display  terminals 
consisting  of  a tvoewr i ter-1 i ke  keyboard  and  CPT  display 
device.  Each  terminal  displays  a DMA  imaae  of  a b 7 o b/te 
terminal  ouffer  located  in  PAM.  Kevooard  input  is 
accomplished  bv  software  translation  of  a keyboard  matrix 
code  into  the  cor resoondi no  ASCII  character  code.  por 
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hardcooy  output  the  NPS  440  includes  a Centronix  serial 
matrix  printer. 

Several  different  auxiliary  storaae  devices  may  o® 
attached  to  the  Sycor  44  0 in  addition  to  the  m i n i - d i s k . 
These  include  maqnetic  tare  drives*  cassette  tape  drives* 
and  floppy  disk  drives.  The  NPS  c on f i au r a t i on  includes  a 
cassette  tape  drive  located  in  the  control  unit.  This  driv» 
provides  compatibility  between  the  Sycor  440  system  and  the* 
Model  340  debuqqer. 

The  Model  340  Communications  Terminal  is  a complete 
system  in  its  own  riqht  which  is  mar<eted  by  Sycor  for 
remote  job  entry  TR.IE.1  applications  [4],  When  utilized  as  a 
hardware  debuoqer,  the  34n  is  auqmentec  with  a*  of  PA1,1  and 
backplane  couolina  to  a special  wire-wraooed  interfaca  board 
in  the  440  control  unit.  Tne  340  debuoqer  is  provider)  with 
a software  package  which  includes  provisions  for  loadinn  and 
dumping  hex  format  croqram  files  between  cassette  tape  and 
440  PAM,  examination  and  modification  of  individual 
locations  in  440  memory*  inserting  breakpoints  and  trams  in 
oroqrams  executing  on  the  440*  and  s i ng 1 e- s t eop i na  through  a 
program  executing  one  instruction  at  a time  [61. 

There  are  several  hardware  characteristics  of  the  Sycor 
440  system  which  stronqly  influenced  the  implementation  of 
MTS.  The  most  important  of  these  are: 

(1)  8080  CPU  architecture 

(2)  terminal  design 

(3)  mini-disk  interface 

(4)  single-state  CPU 


(5)  lack  of  memory  orotection 


The  impact  which  each  characteristic  had  on  the  desian  and 
implementation  of  MTS  is  covered  in  Ref.  1.  For  a nnr» 
detailed  discussion  of  Sycor  440  hardware  characteristics 
see  Ref.  ? . 
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SYCOR  440/MTS  INTFRPACE 


The  Microcomputer  Timeshared  System  was  desianed  and 
built  for  use  on  the  Sycor  440  Clustered  Terminal  Process i no 
System.  For  this  reason  VTS  depends  heavily  on  snec i f i c 
features  of  the  Sycor  implementation  of  an  8060  based 
microDrocessor.  This  dependence  includes  reliance  on  Sycor 
supplied  software  as  well  as  the  440  harawarei  but  becomes 
most  apparent  to  the  user  in  the  two  areas  o*  loaHina  tn» 
system  and  maintaining:  system  files. 

1.  Loadi no  the  System 

The  MTS  object  module  resides  on  the  fjni-aisl'  in  a 
relocatable  format  acceptable  to  the  Svcor  System  loader. 
The  System  Loader  is  called  in  to  memory  ov  sett i na  the 
internal  system  definition  switch  to  3 and  turn i no  tre 
ON /OFF /RESET  tevlock  on  the  control  unit  to  the  RESET 
position.  After  MTS  is  loaded  execution  beoins  with  the 
initial  proaram  load  (TPL)  module.  The  query  REC0VE°f? 
(Y/N)  is  displayed  at  terminal  0.  The  operator  should  enter 
Y if  recovery  is  desired»  otherwise  N.  In  the  event  that 
the  IPL  operation  is  halted  due  to  a file  access  error  Cfile 
non-existent  or  cannot  be  read)  the  messaae  IPL  AbOkTED 
followed  by  a system  file  name  will  appear  at  terminal  0. 
After  correct ino  the  problem  the  ooerator  may  reload  in  to® 
normal  manner.  When  the  IpL  AP0PTED  messane  is  accompanied 
by  the  HARDWARE  ERROR  terminal  alert  it  indicates  ttaf  an 
abnormal  completion  code  was  returnee  by  the  mini-ois^ 
controller  after  a read  operation.  Further  investigation 
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using  the  Sycor  utility  proarams  FIXNAR  op  ..ZAP  may  bp 
required  to  identify  the  problem  f2/51. 

To  summarize/  loadina  WTS  involves  the  followino 

steps: 

(1)  set  internal  system  definition  switch  to  3 

(2)  turn  ON/OFF/RFSET  keylock  to  RESET 

(3)  wait  two  minutes  while  mini-disk  reaches  ooeratino 
soeec  and  all  red  lights  on  control  unit  status  panel 
go  out 

(4)  respond  to  RECOVERY?  auery  with  N to  initialize  a new 
system  or  Y to  recover  from  the  last  operating 
session. 

2.  Recovery  File  - .MTSRCVP 

MTS  supports  limited  recovery  after  a user  task 
causes  a system  crash.  The  recovery  feature  is  implemented 
bv  copying  the  contents  of  the  system  state  block  fSSdl 
after  each  swap  to  a mini-disk  file  known  as  the  recovery 
file.  Since  the  SS8  defines  the  state  of  the  system  at  anv 
instant/  recovery  may  be  accomplished  by  reloading  the 
from  the  recovery  file/  deletinq  the  task  causinq  the  crash/ 
and  proceeding  with  normal  execution.  These  actions  are 
performed  by  the  MTS  TPL  module  when  the  answer  to  the 
RECOVERY?  query  is  Y. 

whenever  Mjg  is  runninq,  a s i nq 1 e-sec t o r file  named 
,MTSRCVR  must  be  listed  in  the  mini-disk  directory.  In  the 
event  this  file  is  deleted/  it  may  be  recreated  unaer  the 
Sycor  operating  3vstem  by  using  the  command 


CREATE  .MTSRCVR  N=1 


The  contents  of  the  recovery  file  at  the  completion  of  an 
operating  session  are  only  meaningful  if  recovery  will  be 
requested  when  MTS  is  next  loaded.  Therefore*  under  normal 
circumstances  this  file  is  not  needed  when  MTS  is  not 
runn i nq . 

3.  Swao  Riles  - .MTSSWPx 

One  of  the  most  fundamental  requirements  on  any 
timesharing  system  is  mai ntainina  independence  of  user  tasks 
executing  concurrently.  MTS  satisfies  this  reoui rement  py 
maintaining  physical  as  well  as  logical  separation  of  all 
user  tasks  in  the  system.  Associated  with  each  of  the  four 
terminal  tasks  is  a mini-disk  file  used  to  store  a core- 
imaae  of  the  task  when  it  is  waitino  for  the  CPU  or  blocked 
oendinq  some  I/O  operation.  At  any  qiven  instant  a task  may 
reside  on  the  disk  in  its  swap  file  or  in  memory*  but  a*  no 
time  can  two  or  more  tasks  reside  in  memory  simultaneously. 

A task's  swap  image  consists  of  17  bytes  reserved  tv 
MTS  for  environment  and  virtual  device  control  data  followed 
by  up  to  48*896  bytes  of  user  task  memory  imaae.  Thus*  the 
maximum  allowable  swao  imaae  is  approximately  48K  bvt**s. 
There  is  no  minimum  value  for  the  size  of  a swap  image.  Tne 
swap  image  size  or*  ecu i va 1 ent 1 v * the  amount  of  memory  space 
available  to  the  user  is  variable  from  0 to  4AK.  In  fact* 
the  user  is  encouraaed  to  use  the  smallest  swap  image  which 
satisfies  his  requirements  as  smaller  swao  images  tenn  to 
improve  system  responsiveness. 
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A 98K  swao  imaqe  will  fill  96  sectors  on  the  mini- 
disk. Therefore  each  of  the  four  swao  files  should  normally 
be  96  sectors  lonq.  In  the  event  that  mini-disk  space  is 
limited?  or  that  user  tasks  do  not  requre  a 08K  swap  imaoe? 
MTS  will  automatically  adjust  to  any  file  size  qreater  than 
16K  (32  sectors).  Sixteen  kilobytes  was  selected  as  the 
minimum  and  default  system  size  since  it  provides  a 
reasonable  amount  of  memory  for  running  the  CP/M  operating 
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If  it  becomes  necessary  to  chanoe  the  size  of  any  or 
all  swao  files?  the  filets)  must  first  be  oeleted  from  the 
mini-disk  directory.  This  is  accomplished  under  the  Pycor 
operating  system  usinc  the  command 
DELETE  <filename> 

where  <filename>  may  be  .MTSSbPO,  .MTSSWP1?  ,MTSS'/«P2?  or 
,MTSSWP3.  The  number  in  each  case  indicates  the  terminal 
with  which  the  file  is  associated.  After  the  file  has  been 
deleted?  it  may  be  recreated  by  usinq  the  command 
CREATE  <filename>  N = 96 

for  each  file  which  has  been  deleted.  If  swao  files  smaller 

than  48K  are  desired?  the  value  of  M in  the  CREATF  command 

strinq  should  be  two  times  the  required  memory  spac**  in 
kiloDvtes?  but  no  less  than  32. 

The  contents  of  the  swap  files  uoon  completion  of  an 

MTS  ooeratinq  session  are  only  meaningful  if  recovery  will 
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other  entries  becomes  number  17. 

The  con f i au r a t i on  file  is  read  by  MTS  durinq  tho 
i n i t i a 1 i z at i on  process  performed  bv  the  IPL  mooule.  The 
filename  is  extracted  from  each  entry  and  input  to  a routine 
which  searches  the  mini-disk  directory.  When  a match  occurs 
the  mini-disk  address  for  the  file  is  read  from  the 
directory  and  entered  in  a virtual  floppy  disk  map  'cable. 
If  no  match  occurs  for  a oiven  configuration  file  entny,  tne 
corresponding  logical  disk  number  is  marked  not  available. 
Any  subsequent  attempt  to  access  that  virtual  disk  will 

result  in  the  terminal  a 1 t ° r t DISK  NOT  AVAIL  CE.3). 

*•» 

The  conf  i ourat  i on  file  may  only  t>e  modified  when 
runninq  under  the  Sycor  ooeratina  system.  Svccr  provides  a 
data  entry  free  form  mode  which  allows  the  terminal  operator 

to  examine  and  modify  the  contents  of  the  file  151.  Extreme 
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care  must  be  exercised  when  uodatina  .MTSCNFG  to  align  eac1, 
entry  properly  in  the  file.  MTS  assumes  the  file  will  be  in 
the  prooer  format  when  read,  and  makes  no  attempt  to 
validate  individual  entries. 

Since  the  information  contained  in  the  configuration 
file  is  of  a permanent  nature  and  can  only  be  recreated  with 
great  difficulty,  the  file  .MTSCNFG  should  never  be  deleted 
from  the  mini-disk  file  directory.  In  the  event  the  file  is 
deleted  erroneously,  a new  file  may  be  created  under  tne 
Svcor  operatinq  system  usinq  the  RFSTGPE  command  and  a 
backup  cassette  labeled  ".MTSCNFG  DUMP".  The  command  is 
entered  as 

RUN  RESTORE  2=/CSST 


with  .MTSCNFG  DUMP  mounted  in  the  cassette  drive.  This 
command  will  build  a new  file  directory  entry  for  .MTSCNFG 
and  establish  a basic  conf iouraf ion  file  with  3?  entries  of 
the  form  .DISKx,  where  x ranaes  from  0 to  31.  This  basic 
file  may  then  he  edited  as  described  above  to  reflect 
current  file  names  and  protection  attributes. 

5.  Virtual  Floppy  Disk  Files 

Each  virtual  floppy  disk  resides  on  a block  of 
logically  contiguous  mini-disk  sectors.  This  block  must  be 
allocated  usina  the  facilities  provides  by  the  Sycor 
operating  system,  specifically  the  command 

CREATE  <filename>  N = < f i 1 e s i z e > 
where  <filename>  is  a 1 to  8 character  name  to  be  entered  in 
the  mini-disk  directory  and  confiauration  file,  and  < f i 1 “ 
s i z e > is  the  length  of  the  file  in  512  b y *■  e mini-disk 
sectors.  For  the  standard  256K  bvte  floppy  disk  <file  si?e> 
eouals  512,  i.e.  (256  * 1 024 ) /5 1 2=5 1 2 . 

Where  a physical  floppy  cisk  has  a fixed  capacity  of 
256K  bytes,  an  MTS  virtual  disk  may  have  any  convenient 
size.  MTS  assumes  that  the  disk  image  is  made  up  cf 
contiguous  128  bvte  floppy  disk  sectors  starting  with  track 
0 sector  1,  proceedino  through  the  26  sectors  of  track  0 to 
track  1 sector  1,  and  so  on  until  the  virtual  disk  file  is 
full.  If  the  virtual  disk  file  size  is  less  than  512  mini- 
disk sectors,  less  than  77  floppy  disk  tracks  will  fce 
addressable.  Conversely,  if  the  file  size  exceeds  512,  t^en 
more  than  77  tracks  will  be  addressable,  uo  to  a maximum  c* 
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256  tracks.  In  either  case  MTS  aut  omat  i c a 1 I v adjusts  the 
uDper  bound  based  on  the  file  size  as  shown  in  the  mini-disk 
di rectory. 

It  is  important  to  note  that  MTS  only  recoqnizes 
virtual  floppy  disk  files  which  are  entered  in  the 
con f i au r a t i on  file.  The  looical  disk  number  associated  with 
a given  virtual  floppy  disk  file  is  determined  by  that  files 
position  in  .MjgCNFG.  When  the  file  is  initially  entered  in 
the  con f i gurat i on  file  a protection  key  and  protection 
attribute  should  also  be  entered#  if  desired. 
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0.  MTS/USER  TERMINAL  INTFRFACE 


1.  Terminal  Interface  Desiqn 

The  general  format  of  each  terminal  display  is  as 

f o 1 lows! 
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The  numbers  are  decimal  and  specify  character  positions 
within  the  status  line  and  display  buffer. 

a.  Status  Line 

The  terminal  status  line  is  used  by  mts  to 
disolay  three  types  of  status  information: 

Cl)  The  current  virtual  drive  and  floppy  disk  assignments 
for  that  terminal . 

(2)  The  size  of  the  user's  swap  imaoe#  i.e.  the  amount  of 
memory  space  currently  available. 

(3)  Error  message  alerts  produced  by  MTS  system  commands, 
or  resulting  from  user  program  calls  on  the  DISPLAY 
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MSG  service  routine  (see  F.?.). 

The  status  line  disolay  format  and  contents  are 
discussed  in  detail  in  section  F. 

b.  Disc  lay  Buffer 

The  disolay  buffer  can  hold  uo  to  a maximum  of 
512  characters.  The  disolay  buffer  also  acts  as  an  innut 
Duffer,  holding  the  incut  data  until  the  user's  program 
requests  it.  Due  to  the  unavoidable  delays  in  user  rroqram 
response  caused  bv  swapping  and  aoqravated  by  the  relatively 
low  data  transfer  rate  of  the  mini-disk,  the  MTS  terminal 
interface  provides  character  echoina  and  simple  line  editino 
features.  This  ensures  reasonable  resoonse  times  to  kev 
activation  by  the  user.  Thus,  incut  data  can  not-  be 
considered  available  to  the  user's  orooram  until  an  innut- 
line termination  character  has  been  received  by  M T ^ . To 
establish  an  incut  buffer  for  a orooram,  the  user  enters  tne 
data  and  terminates  the  line  by  hitting  the  MEM  INE  or  FMTER 
keys  on  the  keyboard.  This  establishes  that  line  as  an 
input  buffer  available  for  orocessinq  bv  the  user's  orooram. 
Note  that  the  kev  combinations  'I/O  CTL  M'  or  'SHIFT  CR' 
(on  the  number  pad)  will  also  result  in  the  termination  of 
an  incut  line.  Either  of  these  keys,  as  well  as  NEWLTNF  and 
ENTER,  may  be  used  for  line  termination. 

Once  an  input  buffer  has  been  established  *he 
user  may  continue  to  input  data  on  the  next  line.  The  user 
may  use  any  of  the  line  editino  or  other  cursor  control 
features  on  this  new  line  of  input  data.  However,  t h i s new 
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line  mav  not  be  terminated  until  the  user's  proaran  has 


processed  the  previous  input  buffer  (see  terminal  alerts 
below). 

Each  character  output  from  the  user's  pronram  is 
displayed  at  the  current  cursor  position.  Each  output 
results  in  all  input  buffer  pointers  beino  reset  to  the 
character  position  at  the  end  of  the  cutout  data.  Thus*  new 
I/O  will  Start  this  point.  This  implies  that  if  tne  user 
had  been  in  the  middle  of  entering  oata  when  the  output 
occurred*  it  must  be  reentered. 

c.  Terminal  Alerts 

The  MTS  terminal  interface  provides  the  user 
with  either  a visual  or  audio  response  to  eacn  kev 
depression.  Normal  visual  response  is  provided  by  display 
of  the  entered  character  and/or  movement  of  tne  display 
cursor.  The  display  cursor  is  a blinkina  underscore 
character  which  marks  the  current  position  on  the  screen. 
Oata  is  always  entered  and  displayed  at  the  current  cursor 
position. 

The  audio  responses  consist  of  either  a beep  or 
click  at  the  terminal.  A terminal  been  alert  will  be 
generated  for  any  of  the  followina  conditions: 

(1)  An  input  buffer  is  waiting  to  be  processed  by  th*» 
user's  proaram  and  the  terminal  user  attempts  to 
terminate  a new  input  line. 

(2)  An  attempt  is  made  to  move  the  cursor  back  oast  the 
start  of  the  current  line.  For  example*  attempting  to 


delete  the  orevious  line  op  character  after  the  line 


has  been  entered  by  a termination  key  will  result  in  a 
been . 

The  terminal  click  alert  is  associated  w i t h fee 
disDlay  scrollina  feature.  Since  the  display  buffer  also 
acts  as  an  inout  buffer*  scrollina  the  disDlav  when  the  51? 
byte  display  buffer  is  full  could  destroy  input  data  which 
has  not  yet  been  processed.  For  example*  the  user  could  b«* 
enterinq  a 51?  character  strina.  Unon  termination  of  that 
input  line*  MTS  will  lock  out  scrollina  until  the  user's 
proaram  has  Drocessed  the  first  bU  characters.  This  pnsures 
that  the  input  data  is  not  destroyed  cv  the  scrollina 
operation.  This  scrollinq  lockout  is  indicated  tc  the  user 
by  a terminal  click  alert. 

?.  Terminal  Key  Functions 

The  terminal  keys  fall  into  five  basic  functional 
groups:  keys  for  entry  of  normal  character  strings*  kpys 
which  affect  the  interpretation  of  the  inout  key  character? 
input  line  termination  keys*  line  editing  and  cursor  control 
keys;  and  number  pad  keys.  These  keys  and  their  functions 
are  described  in  the  following  subsecions.  Within  the 
function  descriptions*  "current  Position"  refers  to  the 
current  cursor  position  on  the  screen.  Any  reference  to  tne 
display  of  a character  in  the  current  position,  also  implies 
that  the  current  position  is  incremented  by  one. 


1 06 


I 


Character  Strinn  Keys 


! 


* 


f 


KEY/SWITCH 


FUNCTION 


0-9 


Soec i a 1 
Characters 


Displays  the  incut  numeric 
character  at  the  current 

oosition  on  the  screen. 

Disolays  th»  innut  special 
character  at  the  current  cursor 
position  on  the  screen. 


A-Z 


Tab/Skip 


Disolays  the  incut  alphabetic 
characters  at  the  current 
position  on  the  screen. 
Alphabetic  characters  am 
displayed  in  upoer  or  lower  c a s ® 
depending  on  the  key  mode  (see 
SHIFT  and  FS  C under  Entry  Moae 
Kevs ) . 

Disolays  a (hori zonal)  tab  sym- 
bol at  the  current  position  on 
the  sc  reen . 


b.  Entry  Mode  Kevs 

KEY/SWITCH  FUNCTION 


FUNCTION 
SELECT (FS ) 


Defines  the  interpretation  nf 
keys  for  special  functions  as 
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defined  in  this  section 


I/O  CONTROL  Defines  the  i n t e rn re t a t i on  of 
(I/O  CTL)  keys  for  special  functions  as 

defined  in  this  section.  Also 
used  in  conjunction  with  the 
alphabetic  keys  to  generate 
appropriate  ASCII  control  cooes. 


SHIFT 

Defines  the 

interpretation 

o f 

keys  used 

for 

two 

(<n 

characters. 

Also 

used 

t o 

capitalize  alsnabetic  characters 
when  the  key  entrv  rode  is  lower 
case  (see  below). 


FS  C Sets  or  clears  the  alphabetic 

key  entry  mode  to  upper  or  lower 
case.  Functions  as  a shift  kev 
lock. 

c.  Line  Termination  Keys 
key/smtch  FUNCTION 

NErt  LTNF;  ENTER?  Terminates  the  current  line  and 

I/O  CTL  M;  establishes  the  just  completed 

SHIFT  CR;  incut  line  as  an  input  buffer 

available  for  processing  by  the 
user's  o roq r am . 

me 


The  cursor  is 


displayed  at  the  left  most 

position  of  the  next  line. 

ERROR  RESFT  Specifies  that  the  input  line 

(MTS  CMD)  which  it  terminates  is  to  be 

processed  by  WTS  as  a system 
command . 

d.  Line  Editino  and  Cursor  Control  Keys 

KEY/SWITCH  FUNCTION 


NEXT  F M A T Deletes  all  characters  from  the 

(Line  Delete)  current  position  hack  to  the 

start  of  the  current  line. 

BACK  SPACE  Deletes  the  previously  entered 

(Char  Delete)  character. 

FS  5 or  I/OCTL  S Clears  the  display  buffer  (not 
(Clear  Screen)  the  status  line)  and  leaves  tn» 

current  position  at  the  upper 
left  position  of  the  display 
buffer. 

<---  (Cursor  Left)  Moves  the  current  position  on® 

to  the  left.  Does  not  delete 
previous  entry(  but  allows 
reentry. 


— ->(Cursor  Right)  Moves  the  current  position  one 


1 OR 


""" 1,1111  11 


'■■■  ! LP  , . HJ,|,  i 

to  the  rioht.  Hoes  not  aelete 
previous  entry,  but  allows 
reent ry  . 

e.  Number  Pari  Keys 

The  number  pad  keys  consist  of  10  numeric  digits 
and  8 ASCIT  control  characters  located  on  the  rioht  side  of 
the  keyboard.  The  diaits  function  in  the  same  manner  as  tne 
other  numeric  diqits  on  the  keyboard.  The  ASCII  control 
characters  are  displayed  when  the  SHIFT  key  is  depressed  in 
conjunction  with  the  anorooriate  kev.  The  only  control 
character  which  affects  the  disolav  is  SHTFT  Lp  (see  Line 
Termination  Keys). 

3.  MTS  System  Commands 

System  commands  are  a set  of  commands  whicn  rrnyige 
the  user  with  a means  of  communication  with  MTS  from  the 
terminal.  These  commands  allow  the  user  to  loain  to  MTS; 
quit  MTS;  attach  virtual  f 1 ooov  disks;  protect,  restrict, 
and  unprotect  virtual  floppy  disks;  and  soecify  the  virtual 
memory  size  to  be  used. 

a.  General  Characteristics 

A MTS  command  seauence  may  be  entered  anytime 
after  the  i n i t i a 1 i z a t i on  or  r e i n i t i a 1 i za t i on  of  MTS.  The 
user  enters  the  desired  command  sequence,  followed  by  the 


EPROR 

RESET 

key. 

This 

s i ana  1 s 

the  ooe r a t i na 

system  that 

there 

i s 

an 

MTS 

command 

to  be 

processed. 

Any  errors 

det  ec  ted 

i n 

the 

command 

sequence  will  result 

in  an  error 
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alert  messaae  displayed  in  the  MTS  message  field  on  the 
status  line.  Section  E describes  the  MTS  status  line 
disolay  ana  provides  a summary  of  the  error  messaoes. 

b . Synt  a*  Pules 

The  following  rules  should  be  used  to  interpret 
the  syntax  for  each  system  command  given  in  section  D.3.e. 

(1)  The  command  may  be  entered  in  upper  or  lower  case. 
MTS  converts  the  commands  to  unc°r  case  for 
process i ng . 

( 2 ) Each  entry  in  the  command  sequence  must  he  senarated 
Dy  one  or  more  snaces. 

( 3 ) The  entire  command  name  may  be  used  to  specify  the 
command.  However  only  the  first  letter  o*  the  command 
is  reouiredf  as  indicated  bv  the  underscore  in  tne 
syntax.  MTS  validates  only  the  first  letter  o t f h® 
command  name. 

( U ) Parameters  are  shown  in  lower  case  and  enclosed  bv 
ineauality  signs  (<  >).  Each  parameter  name  is  a 

variable  which  must  be  replaced  bv  the  appropriate 
character  strinq  or  decimal  number  entered  bv  the 
user. 

(5)  Parameters  mav  be  required  or  optional/  deoendino  on 
the  command.  notional  parameters  are  srecified  by 
enclosing  the  oarameter  in  brackets  (l  1).  Tf  a 
parameter  is  desianated  as  optional/  it  may  be  omitted 
from  the  command  seauence  (sen  section  0.3.d). 

The  designation  [<disk  nr>  {/<kev>l 1 indicates  that 

1 1 1 


(6) 


the  entire  parameter  seauence  is  optional, 


and  that 


<disk  nr>  may  appear  without  /<key>.  The  converse, 
however,  is  not  true. 

(7)  If  parameters  are  entered  in  a command  sequence  they 
must  be  in  the  order  specified  in  the  syntax.  for 
example,  <disk  nr>  may  not  be  entered  before  <drive 
1 t r>. 

(P)  The  notation  (error  reset)  at  the  end  of  each  command 
st  rina  is  a reminder  to  the  user  that  each  MTS  command 
seauence  must  be  terminated  by  the  ERROR  RESET  key. 

c.  Parameter  Definitions 

The  system  commands  have  four  types  o+ 

parameters  : 

(1)  <drive  1 t r>  - must  be  one  of  the  alphabetic  characters 
A throuqh  H.  It  specifies  one  of  the  eiaht  virtual 
disk  drives  availaole  to  a terminal  user. 

(2)  <disk  nr>  - must  be  a decimal  number  in  the  ranqe 
0-31.  It  specifies  one  of  up  to  32  virtual  flonov 
disk  files  on  the  Sycor  mini-disk. 

(3)  /<key>  - a strinq  of  not  more  than  four  characters, 
always  preceded  bv  the  special  character  '/'  which 
designates  the  strinq  as  a key  parameter.  All  valid 
ASCII  characters  are  acceptable  includina  blank,  slash 
(/),  and  other  special  characters. 

(a)  < memo r y size>  - must  be  a decimal  value  in  the  ranqe  0 
to  yP,  which  specifies  the  user's  swao  imaqe  size  in 
kilooytes.  The  default  value  for  a user  swap  imaoe  is 
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16K 


d.  Default  Parameter  Values 

Certain  svstem  commands  allow  the  user  to  omit- 
the  <drive  1 t r > and/or  < d i s k nr>  parameters.  In  these 
casesi  NTS  determines  the  aoorooriate  drive  letter  and  disk 
number  by  seannina  its  allocation  tables  for  the  first 
available  virtual  drive  or  virtual  disk,  as  aoorooriate.  If 
one  is  found,  it  is  allocated  to  the  reauestino  user. 
Otherwise  the  aoorooriate  error  messaoe  is  displayed. 

The  <key>  parameter  is  optional  only  if  tKe  disk 
requested  has  no  protection  attributes  specified.  Thus  there 
is  no  default  <kev>  value.  As  previously  mentioned,  tne 
default  <memory  size>  parameter  is  16K. 


e.  Commana  Descriptions 

The  followinq  oaqes  describe  in  detail  each  o* 
the  system  commands: 


(1) 

ATTACH 

(?) 

LOGIN 

(3) 

PROTECT 

(«) 

QUIT 

(5) 

RESTRICT 

(6) 

SIZE 

(7) 

UNPROTECT 
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SYSTEM  COMMAND  ATTACH 


» 

Func  t i on  : 

To  attach  a virtual  floppy  disk  to  a virtual  disk  drive 
for  use  by  a user  at  a soecific  terminal. 

Synt  ax : 

ATTACH  t<drive  1 1 r > 1 (<disk  nr>  [/<key>] ) (error  reseM 


Oesc  r i ot i on : 

This  system  command  simulates  the  physical  operation  of 
loading  virtual  disk  <disk  nr>  into  virtual  arive  <drive 
ltr>.  All  parameters  are  optional*  section  D . t . d 
describes  the 
are  omitted. 


Error  Messaaes: 

invalid  cmd 

ORIVE  NOT  AVAIL 


DISK  NR  ERROR 
DISK  IN  USE 


DRIVE  LTR  ERROR 
DISK  NOT  AVAIL 


KEY  ERROR 


Examol es : 

ATTACH 

A 

3 /USRl 

A 

c 

attach 
a 1 

5 

/ vd#  1 

1 1 a 


default  values  when  optional  parameters 


- Syntax  error  in  command  sequence. 

- Drive  letter  has  not  been 
snecified  and  there  is  no  drive 
presently  available  for  assignment. 

- Disk  number  entered  is  greater 
than  31 . 

- Disk  number  specified  is  presently 
allocated  with  read/write  access  to 
anot  her  user . 

- Drive  letter  entered  is  not  one  of  the 
letters  A throuqh  H. 

- Either  disk  number  has  not  been 
specified  and  there  is  no  disk 
presently  available  for  assignment;  or 
the  specified  disk  is  not 

available  for  assignment. 

- The  specified  disk  reauires  a key 

and  either  a key  has  not  been  entered 
or  the  entered  key  did  not  match. 


SYSTEM  COMMAND 


LOGIN 


i 


F unc  t i on : 

Links  the  terminal  user  to  MTS  and  orovides  the  initial 
load  of  the  user's  proqram  or  operatino  system  (default 
system  i s CP/M) . 


Synt  ax  : 

LOGIN  t<disk  nr>  t/<kev>11  (error  reset) 


Description: 

This  system  command  notifies  MTS  that  the  reauestim 
terminal  is  now  active#  and  simulates  the  physical 
cold-start  bootstrap  operation  of  the  user's  system. 
The  bootstrap  load  always  takes  place  from  virtual  drive 
A.  The  virtual  disk  (and  associated  key#  if  any) 
attached  to  this  drive  may  be  specified  as  a param“ter. 
The  default  is  disk  nr  0,  which  is  a read  onlv  dis*  and 
always  contains  the  CP/M  ooeratina  system. 


Error  Messaaes: 

DISK  NR  ERROR  - Disk  number  entered  is  areater 

than  31. 

DISK  IN  USE  - Disk  number  specified  is  presently 

allocated  with  read/write  access  to 
anot  her  user . 

DISK  NOT  AVAIL  - The  specified  disk  is  not  available 

for  ass i qnment  . 

HARDWARE  ERROR  - Abnormal  completion  status  was 

returned  by  the  mini -disk  controller 
following  a write  operation.  This 
may  indicate  that  the  last  virtual 
disk  written  to  was  not  closed 
properly  and  data  has  been  lost. 

INVALID  CMD  - Syntax  error  in  command  sequence. 


E xamo 1 es : 

LOGIN  3 /D1 
L 15 

loqin  25  /d25 

1 
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S Y S T EM  command 


PRDTFCT 


Func t i on  J 

Adds  the  read/write  protection  attribute  to  the 
soecified  virtual  disk. 


Svnt  a*  : 

PROTECT  <disk  nr>  /<key>  (error  reset) 


Descriot ion! 

This  system  command  provides  the  user  with  tne  means  (or 
on-line  assianment  of  a protection  <key>  to  <disk  nr>. 
This  protection  may  also  be  aaded  off-line  usi ra  the 
Sycor  «£I0  system  software  (see  section  C.5). 


Error  Messaoes: 

DISK  NR  ERROR 

HARDWARE  ERROR 


INVALID  CMD 
KEY  ERROR 


- Disk  number  entered  is  oreater 

than  31. 

- Abnormal  completion  status  was 
returned  by  the  mini-disk  controller 
followinq  a read  or  write  operation. 

- Svnt  a*  error  in  commano  sequence. 

- The  specified  disk  is  already 
protected.  To  chanoe  protection  kevs 
use  UNPROTECT  with  current  key  and 
then  PROTECT  with  new  key. 


E x amp  1 es  : 

PROTECT  1 / VFD5 
protect  10  /keyl 
p 2 /u#?0 
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SYSTEM  COMMAND 


QUIT 




Func  t i on  : 

Terminates  the  terminal  user's  link  to  MTS. 
Syntax : 

QUIT  (error  reset) 


Description: 

This  system  command  notifies  MTS  that  the  requestino 

terminal  is  no  longer  active. 

Error  Messaaes: 

HARDWARE  ER°DR  - Abnormal  completion  status  was 

returned  bv  the  mini-disk  controller 
followinq  a write  operation.  This  rev 
indicate  that  the  last  virtual  disk 
written  to  was  not  closed  nrooerlv  and 
data  has  been  lost. 

INVALID  CWD  - Syntax  error  in  command  sequence. 


Examol es : 

QUIT 
qui  t 
Q 
q 


SYSTEM  COMMAND  RFSTRTCT 


Func t i on  : 

Adds  the  read  restriction  attribute  to  the  specified 
virtual  disk. 


Syntax: 

RESTRICT  <disk  nr>  /<kev>  (error  reset) 


Description: 

This  system  command  provides  the  user  with  the  means  tor 
on-line  assignment  of  a "read  only"  restriction  to  <oisk 
nr>.  This  allows  the  user  to  soec i f v a previously 
protected  virtual  floppy  disk  as  available  to  other 
users  for  read  only  access. 


Error  Messaaes: 

DISK  NR  ERROR  - Disk  number  entered  is  or^aterl 

than  31. 

INVALID  CMD  - Syntax  error  in  command  seauence. 

KEY  ERROR  - The  specified  disk  reauires  a key 

and  either  a key  has  not  been  entered 
or  the  entered  key  did  not  match. 


Examp l es : 

RESTRICT  3 /ID  1 
R a / I DR 
restrict  13  /usr 3 
r 16  /I 
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SYSTEM  COMMAND 


STZF 


Func  t i on  : 

Specifies  the  memory  size  to  be  allocated  to  the 
terminal  user. 

Svn  t ax: 

SIZE  <memorv  size>  (error  reset) 


Description: 

This  system  command  sets  the  size  of  the  user's  swan 
imaae.  The  ranqe  of  values  is  0-48K.  The  default  vaue 
after  loqin  is  1 fc>  K . is  entered. 


Error  ^essaoes: 

INVALID  CMO  - Syntax  »rror  in  command  seauence. 

OUT  OF  ROUNDS  - Either  the  size  parameter  entered 

does  not  fall  in  the  ranqe  of 
0-^F;  or  the  Sycor  4U0  swap  file 
is  not  1 arae  enouoh  to  hold  this 
size  swao  imaae  (see  section  C.3). 


Exampl es : 

STZE 
S 3? 

size  4 8 

s 0 
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SYSTEM  COMMAND 


UNPROTFCT 


Function: 

To  remove  a previously  entered  protection  key  from  the 
specified  virtual  f 1 ocov  disk. 


Syntax  : 

UN PROTECT  <disk  nr>  /<key>  (error  reset! 


Desc  r i pt i on  : 

This  system  command  provides  the  user  with  the  means  for 
on-line  removal  of  all  projection  attributes  from  <disk 
nr>.  This  protection  may  also  be  deleted  offline  usino 
the  Sycor  490  system  software  (see  section  C.*'). 


Error  Messaaes: 

DISK  NR  ERROR  - Disk  number  entered  is  oreater 

than  "t  1 . 

HARDWARE  ERROR  - Ahnormal  completion  status  was 

returned  by  the  mini-disk  controller 
followinq  a read  or  write  operation. 

INVALID  CMD  - Syntax  error  in  command  seauence. 

KEY  ERROR  - A protection  kev  is  required  and 

either  no  kev  was  entered*  or 
the  entered  key  did  not  match. 


Exampl es : 

UNPROTECT  IB  /NR  9 
U 12  /OR 64 
unprotect  7 /Ovfd 
X 
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E.  MTS  STATUS  LINE  MESSAGES 

The  MTS  ooerating  system  utilizes  the  first  line  of  each 
terminal  for  system  status  and  error  message  oisolays.  Toe 
status  line  is  64  characters  in  length  and  is  divided  into 
three  disolay  areas  as  shown  below. 

STATUS  LINE 

0 3d  an  47  48  b7 

: v f o : m s : m s g \ 


where 

VFD  - Virtual  Floooy  Disk  Status  Display 
VS  - Memory  Size  Display 
MSG  - Error  Messaoe  Display 

1.  Virtual  Flonpv  Disk  Status  Display 

This  display  contains  information  on  the  virtual 
drive  and  disk  assignments  currently  in  effect.  For  each 
attached  virtual  floppy  disk  the  following  will  be 
di sol ayed: 

(1)  drive  letter 

(2)  disk  number 

(3)  restriction  indicator  (r  or  blank) 

For  example*  if  the  user  has  attached  disk  number  3 to  drive 
A and  disk  number  25  (which  is  restricted)  to  drive  C*  the 
status  disolay  would  appear  as  follows: 
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0 


39 


1 0 


J A = 0 3 C = 25r 


2.  Memory  Size  Disolav 


The  center  of  the  status 

line  display 

shows 

the 

current 

memory  site  for  that  user 

and 

the  "MIS" 

header. 

Eo  r 

e x amp  1 e , 

»f  the  system  default  memory 

size  were 

being 

used* 

the  display  would  anpear  as  follows: 

40  47 

16K  MTS 


3.  Error  Messaoe  Display 

All  MTS  system  commands  are  validated  and  an  error 
alert  qenerated  if  any  syntax  errors  are  * o u n d . The  last  16 
positions  of  the  status  line  are  reserved  for  tnese 
messaqes.  A valid  system  command  will  clear  the  error 
messaqe  display  of  any  previous  error  alert.  T^e  followino 
is  a summary  of  system  error  messaqes. 

MESSAGE  MEANING 


Initial  condition?  also  the  status  messaqe 
area  is  cleared  followinq  the  procession 
of  a valid  system  command. 

Disk  number  soecified  is  presently  allo- 
cated with  read/write  access  to  another 
user . 


(Blank  Display) 


DISK  IN  USE 
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DISK  NOT  AVAIL  Either  the  disk  number  has  not  been  speci- 
fied and  there  is  no  disk  presently 
available  for  assignment;  or  specified 
disk  number  is  not  available  for 
ass i qnment  . 

DISK  NR  ERROR  Disk  number  entered  is  rjreater  than  31. 

DRIVE  LTR  ERROR  Drive  number  entered  is  not  one  of  the 

letters  A throuoh  n . 

DPIVE  NOT  AVAIL  Drive  letter  has  not  been  specified  and 

there  is  no  drive  presently  available  for 
ass i qnment  . 

HARDWARE  ERROR  Abnormal  completion  status  was  returned  bv 

the  mini-aisk  controller  follcwinq  a read 
or  write  operation.  wav  indicate  hardware 
errors  on  peripheral  devices  as  additional 
devices  are  included  in  the  system. 

INVALID  CMD  Syntax  error  has  been  detected  in  the 

command  seauence. 

KEY  ERROR  The  specified  disk  reaui res  a key  and 

either  a key  has  not  been  entered  or  th« 
entered  key  did  not  match. 

OUT  OF  ROUNDS  A numeric  parameter  has  been  specified 

which  exceeds  the  valid  bounds  for  that 
parameter. 
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TASK  DELETED 


When  RECOVERY  is  specified  aurina  svs^e" 
i n i t i a 1 i zat i or , this  messacie  is  displayed 
at  the  terminal  which  was  executinr  when 
the  svstem  failure  nccurrea.  It  indicates 
that  this  terminal  user  must  reestablish 
the  environment. 


\?U 


F.  MTS/USER  PROGRAM  INTERFACF 

1.  Proqram  Interface  Oesiqn 

MTS  was  desianed  to  provide  a timeshared,  virtual 
8080  microprocessor  environment  for  m i c r oc omru t e r systems 
development.  The  term  virtual  is  appropriate  here  because 
the  user  actually  interfaces  with  MTS  for  many  services 
normally  provided  dv  hardware  in  a dedicated  OPll 
environment.  A software  interface  between  user  proarams  and 
the  Svcor  4^0  hardware  is  necessary  in  order  to  allocat®  the 
hardware  resources  eouitablv  and  efficiently,  while  at  the 
same  time  satisfyino  the  service  reauirements  of  several 
competing  user  oroqrams. 

The  MTS/user  croara*  interface  consists  of  a set  of 
service  routines  which  may  be  called  by  a user  program 
throuah  a sinol*  entry  point  to  perform  terminal  I/O,  access 
virtual  f 1 oppv  disks,  or  modify  the  user's  virtual 
environment.  The  desiqn  was  heavily  influenced  fcv  the  CP/M 
operatinq  system  which  uses  a similar  scheme  for  I/O. 

The  set  of  service  routines  may  be  looicallv  divided 
into  two  types  of  calls  on  MTS.  The  first  tvpe»  svstem 
calls?  perform  the  same  functions  for  a user  program  as 
system  commands  provide  for  the  user  at  a terminal  (0.3). 
The  functions  deal  with  modifyina  the  user's  current  virtual 
environment  by  chancinq  memory  size?  attaching  various 
virtual  disks  to  virtual  drives?  or  even  looqina  on  ana  off 
the  svstem.  Service  calls  are  the  second  type  of  call 
provided  by  the  MTS  software  interface.  Service  calls  are 
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used  to  perform  terminal  I/O  and  access  virtal  flopoy  ai sks 


A call  to  MTS  takes  the  form 

<va 1 ue>  = MTSf<fid>»<oarm>) 

The  first  arqumentr  <fid>.  is  a number  from  0 to  17  which 
identifies  the  function  reauesfed.  The  <oarm>  arqument  mav 
be  a oarameter  valuer  if  only  a single  Parameter  is 
required/  or  the  address  of  a parameter  list  if  more  than 
one  parameter  is  required.  In  each  case  MTS  returns  <value> 
uDon  completion  of  the  requested  operation.  This  returned 
value  may  be  an  ASCII  character  coder  an  error  coder  or  in 
several  cases  have  no  s i qn i f i c anc e . ^oth  system  calls  and 
service  calls  are  formed  as  described  above.  The  svnta*  and 
function  of  each  call  are  described  in  the  fol Inking 
sections. 
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2.  System  Calls 


All  system  commands  available  to  a user  at  a 
terminal  are  also  available  to  a user  pronram  throuon  svs^e" 
calls.  An  additional  call  is  provided  which  will  display  an 
appropriate  terminal  alert  at  the  user's  terminal  if  entered 
with  an  error  code.  Table  1 summaries  the  ream  red 
arguments  and  return  values  of  each  system  call. 

TABLE  1 


SYSTEM 

CALL  SUMMARY 

FID 

M A M £ 

PARM 

VAL  UF 

0 

ATTACH 

list 

prror 

code 

1 

DISPLAY  MSG 

error  e ode 

none 

f 

LOGIN 

list 

err  o •* 

code 

3 

PPQTECT 

list 

error 

code 

i 

QUIT 

none 

none 

5 

RESTRICT 

list 

error 

code 

6 

SIZE 

s i ?e 

error 

code 

7 

UNPPQTErT 

list 

p r r o r 

code 

a.  Arguments 

Each  system  call  is  identified  by  a number  which 

i 

MTS  associates  with  a particular  service  routine.  in 
addition  to  this  function  identifier,  MTS  may  require  one  on 
several  additional  carameters  to  perform  the  requested 
service.  tNhen  more  than  one  parameter  is  required,  MTS  must 
be  passed  the  address  of  a byte  vector  containina  these 
parameters.  Each  system  call  requires  that  this  vector 
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conform  to  some  fixed  format.  In  qeneral  each  byte  of  the 
vector  wili  contain  some  numeric  value  or  an  SSC1I  cnaracter 
code/  but  situations  mav  arise  when  an  optional  parameter  is 
not  specified.  In  such  cases  the  cor resoonoi no  byte  in  the 
parameter  vector  must  be  filled  with  the  value  FFH. 

b.  System  fall  Descriptions 

The  followinq  raoes  describe  in  detail  each 

system  call. 


SYSTEM  CALL 


ATTACH 


Func t i on : 

To  attach  a virtual  flooDy  disk  to  a virtual  disk  drive 
for  use  by  a user  at  a soecific  terminal. 


A rgument  s : 

FID  = 0 

PARV  s address  of  parameter  vector 

bvte  0:  drive  number  where  a = 0,  b=l,  etc. 

Dyte  1:  disk  number  • 0 to  M 

bytes  2-5:  Protection  key  - 0 to  4 ASC1T  characters 


Desc  r i ot i on : 

This  call  simulates  the  physical  oneration  of  loanino 
virtual  disk  <disk  nr>  into  virtual  drive  <drive  nr>. 
All  parameters  are  optional.  If  disk  and/or  drive  nr  is 
not  specified  MTS  searches  the  disk  or  drive  mao  taKle 
respectively  for  th«*  first  available  entry.  A 
protection  key  is  only  reauired  if  the  virtual  dis<  to 
be  attached  has  been  assianed  read/write  protecting 
The  call  returns  an  error  code  upon  comrletion. 


Error  Codes: 

1 - Operation  successful 

2 - Either  disk  number  has  not  been  soec i f i ed  and  there 

is  no  disk  presently  available  for  assignment;  or 
the  specified  disk  is  not  available  for  assianrent  , 

3 - Disk  number  specified  is  presently  allocated  with 

read/write  access  to  another  user. 

<1  - Disk  number  specified  is  greater  than  31. 

5 - The  specified  disk  reouires  a key  and  either  a key 
has  not  been  entered  or  the  entered  kev  did  not 
match. 

b - Drive  number  specified  is  oreater  than  7. 

10  - Drive  number  has  not  been  specified  and  there  is  no 
drive  presently  available  for  assianment. 
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SYSTEM  CALL 


DISPLAY  MSG 


Function: 

To  display  a terminal  alert  in  the  status  message  area 
of  the  user’s  terminal. 

Argument  S : 

FID  = 1 

P A RM  = error  code 


Descript  ion: 

This  call  takes  an  error  code  as  input  and  displays  tho 
corresponding  nreaefined  terminal  alert  messaoe  on  t h a 
user's  terminal.  The  D T S D L A Y MSG  system  call  provides 
the  only  way  for  a user  to  disrlav  messages  on  tne 
terminal  status  line.  No  value  is  returned  by  tMs 
system  call. 


Action: 

0 - blank 

1 - INVALID  CVD 

2 - DISK  NOT  AVAIL 

3 - DISK  IN  USE 

U - DISK  NP  ERROR 

5 - KEY  ERROR 

6 - DRIVE  LTR  ERROR 

7 - OUT  OF  BOUNDS 
A - HARDWARE  ERROR 
9 - TASK  DELETED 

10  - DRIVE  NOT  AVAIL 
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SVSTEM  CALL 


LOT,  IN 


■ 


F unc t i on  : 

Reinitializes  the  user's  WTS  environment  and  rehoots  the 
user's  system  from  drive  A. 

Argument  s I 
FID  = 2 

PARV  s address  of  parameter  vector 
byte  0:  disk  number  - 0 to  31 

bytes  1 -4 : protection  key  - 0 to  0 ASCII  characters 


Description: 

This  system  call  creates  a reinitialized  ,JI  T S environment 
for  the  user  program,  ve*ory  size  is  set  to  1 b K and  the 
specified  disk,  if  any,  will  he  attached  to  drive  A.  It 
no  disk  number  is  specified,  disk  number  0 containino 
the  CP/M  system  is  attached.  Drive  assionment  and 
memory  size  will  be  displayed  on  the  status  line  o*  toe 
user's  terminal.  The  user  system  is  then  rebooted  from 
drive  A . 


Error  Codes: 

0 - Operation  successful 

2 - The  specified  disk  is  not  available  for  assionment. 

3 - Disk  number  specified  is  currently  allocated  with 

read/write  access  to  another  user. 

4 - Disk  number  specified  is  greater  than  31. 

5 - The  specified  disk  reaui res  a key  and  either  a kev 

has  not  been  entered  or  the  entered  kev  did  not 
match  . 

fl  - Abnormal  completion  status  was  returned  by  the 
mini-disk  controller  following  a write  operation. 
This  may  indicate  that  the  last  virtual  disk 
written  to  was  not  closed  orooerly  and  data  has 
been  lost. 
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SYSTEM  CALL 


QUIT 


Func  t i on  : 

Logs  the  user  off  MTS. 


Argument  S t 
FID  = 4 

PARM  = none  reaui red 


Description: 


This  System 
croaram  i s 
returned  to 
through  the 


call  notifies  MTS  that  the  recuesti 
no  lonaer  active.  Control  will 
the  user  oroaram.  The  user  must 
terminal  to  regain  system  facilities 


no  u s e r 
no  t 0 e 
1 on  i n 


Error  Cooes: 

0 - Ooeration  successful. 

8 - Abnormal  comoletion  status  was  returned  hy  tn« 
mini-disk  controller  following  a write  onerat inn. 
This  may  indicate  that  the  last  virtual  disk 
written  to  was  not  closed  orooerly  and  data  has 
been  lost.  Tf  this  error  code  is  returned*  the 
terminal  alert  HARDWARE  EPROR  is  automatically 
displayed  in  the  status  message  area  of  the  usen's 
terminal . 
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SYSTEM  CALL 


SIZE 


Func  t i on  : 

Set  the  amount  of  memory  available  t o the  user. 


A rqument  s : 

FID  = 6 

PARM  = memory  size  in  kilobytes 


Desc  rot i on : 

This  system  call  adjusts  the  size  of  the  user’s  swao 
imaae  to  the  soeeified  value.  The  value  must  *aH  in 
the  ranae  0 to  46,  and  also  must  not  be  areater  th3n  the 
size  o * the  swap  file  associst»a  with  the  user's 
terminal . 


Error  Codes: 

0 - Operation  successful. 

7 - Either  specified  size  exceeds  4&K,  or  a valua  less 
than  48*  exceeds  the  size  of  the  available  swap 
file. 
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Service  Calls 


The  MTS  environment  currently  provides  a virtual  CRT 
terminal  as  the  primary  I/O  device  and  virtual  floppy  aisk 

drives  for  auxiliary  storaoe.  Access  to  both  of  these 

I 

virtual  devices  is  throuoh  MTS  service  calls.  A summary  of 
the  service  calls  shoxinq  parameters  and  returned  values  is 
q i ven  in  Table  2 . 

TAbLE  2 

SERVICE  CALL  SUMMARY 


FID 

NAME 

PARM 

value 

* 

TERMINAL  STATUS 

none 

true/false 

0 

READ  TERMINAL 

none 

character 

10 

WRITE  TERMINAL 

character 

none 

1 1 

WRITF  PRINTER 

character 

none 

1? 

SELECT  DRIVE 

drive  nr 

error  code 

13 

SET  DMA 

dma  address 

error  c ode 

14 

SET  TRACK' 

t rack  nr 

none 

15 

SET  SECTOR 

sector  nr 

error  code 

16 

READ  FLOPPY 

none 

none 

17 

WRITE  FLOPPY 

none 

none 

a.  Virtual  Terminals 

The  MTS  virtual  terminal  simulates  the  operation 
of  a serial  half-duplex  console  device.  Single  ASCIT 
characters  mav  be  passed  from  the  terminal  keyboard  *0  a 
user  proaram,  or  from  a user  croqram  to  the  terminal  for 
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display.  A service  call  to  MTS  is  required  to  pass  each 
character.  MTS  also  provides  a terminal  status  service  call 
which  allows  a user  proaram  to  test  the  status  of  a 
terminal . 

The  user  should  keep  in  mind  that  characters  are 
actually  being  passed  between  his  program  ana  the  terminal 
display  buffer  (0.1. b).  This  means  that  input  need  not  o° 
echoed  by  the  user's  program  since  it  already  appears  on  h h e 
display.  Simple  line  editinq  is  also  provided  by  MTS  cn  t n e 
input  data  prior  to  matcina  that  data  availaole  tor 
processina  by  the  user's  rroqram. 

(he  user  can  directly  contribute  to  improved 
system  response  by  proper  use  of  the  terminal  service  cal's. 
It  is  common  practice  when  writing  c on ve r sa t i on a 1 programs 
to  implement  a "aet  character"  routine  to  Hanale  input  from 
the  terminal.  Norm. ally  this  routine  does  little  more  than 
repeatedly  test  the  terminal  status  until  it  finas  input 
waitinq.  In  the  MTS  environment  a more  efficient  method  o * 
accomplishing  the  same  goal  is  to  immediately  read  from  the 
terminal  without  testing  for  status.  If  incut  is  waitinq, 
the  first  character  will  be  passed  immediately.  More 
importantly/  if  there  is  no  input  waitinq,  MTS  will  block 
the  user's  croqram  until  a character  is  entered  at  tn» 
keyboard.  The  blocked  program  may  be  swapped  out  ana  tne 
CPU  allocated  to  another  user.  This  method  of  implementing 
conversational  programs  takes  advantage  of  unproductive 
waitinq  time  in  one  user  program  to  service  additional 
users . 
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Virtual  Florov  Disk  Drives 


The  MTS  virtual  floppy  disk  drive  orovides 
auxiliary  stoi'aae  for  user  cronrafS  on  virtual  floppy  aisks. 
These  hard-sectored  disks  have  1 ? bytes  per  sector,  26 
sectors  per  track,  and  a maximum  number  of  tracks  determined 
bv  the  size  of  the  file  containina  the  disk  image  (C.S). 
Each  user  has  eight  drives  available  for  dedicated  use. 

Drive  A is  activated  when  the  user  loos  in  and 
serves  as  the  user  system  load  device.  In  a process  which 
simulates  a cold-starf  bootstrap  load  the  first  four  sectors 
on  track  0 are  read  into  the  user's  memory  space  at  location 
4 0 0 0 H . MTS  assumes  that  these  sectors  contain  executable 
code  which  will  load  the  remainder  of  the  user's  system. 
Unless  another  disk  is  soec i f i ed  in  the  LOUT N command 
string,  a read-only  disk  containing  the  C P/M  operation 
system  will  be  attached  when  drive  A is  activated. 

The  user  mav  activate  any  or  all  o*  rne 
remaining  virtual  drives  bv  attachina  a virtual  disx.  This 
is  accomplished  from  the  terminal  by  enterinq  the  ATTACH 
system  command  or  directly  from  the  user's  oroqram  hy  a call 
to  MTS.  Althouoh  no  direct  method  for  detachino  a virtual 
disk  is  orovided  by  MTS,  the  same  effect  is  produced 
indirectly  by  overrioina  the  current  drive  assionment  with  a 
second  ATTACH  command.  ‘a  hen  the  second  1 1 o P o y disk  is 
attached  MTS  closes  the  previously  attached  disk  and 
releases  it  for  use  elsewhere. 

Data  transfer  between  a virtual  disk  and  a user 
program  utilizes  a l?d  byte  buffer  in  the  user's  program 
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space  called  a DMA  buffer.  The  name  is  arrived  from  mip 
nature  of  the  transfer  ooeratinn:  to  the  user  proaram  it 
appears  that  data  transfer  is  by  direct  memory  access. 

Before  the  user  prooram  can  access  a particular 
virtual  disk  sector  the  user  must  specify  a complete  sector 
address  and  a DWA  Puffer.  A complete  sector  address  consists 
of  drive*  track#  and  sector  numbers.  Note  that  N'TS  will  not 
allow  a virtual  drive  to  be  selected  until  a disk  has  Poem 
attached.  A DMA  buffer  is  defined  by  its  base  address.  I S 
provides  a service  call  to  enter  each  of  these  four  values. 
Once  a value  has  been  entered  it  will  be  used  for  all 
subseauent  virtual  disk  accesses  until  redefined  by  a second 
service  call. 

C.  ArqumentS 

Service  calls  have  rh»  same  form  as  other  ca'ls 
to  MTS.  A numerical  function  identifier  is  associated  with 
each  call  to  identify  the  service  aesired.  The  second 
argument  is  a s i nal e parameter  in  most  cases#  although 
several  of  the  service  calls  reouire  no  second  aroument. 

d.  Service  Call  Descriptions 

The  followinq  naaes  describe  in  detail  each 
individual  service  call. 
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SERVICE  CALL 


TERMINAL  status 


Ftjnc  t ion! 

Interronate  the  status  of  the  user's  terminal. 

A rgument  s ! 

FID  = 6 

PARM  = none  required 
Desc  r i ot i on  : 

This  service  call  returns  a logical  value  answering 
question  "Ts  terminal  inout  waiting?"  TFPMTNAl  STATUS 
should  not  he  user  in  those  situations  where  no  further 
processing  can  he  accomplished  until  terminal  input  is 
available.  In  such  a case  it  is  more  efficient  to  use 
the  READ  TERMINAL  service  call  to  allow  processing  of 
other  user  tasks  while  waitino. 

Value! 

00H  - all  terminal  innut  processed 
FFH  - terminal  input  waitino 


: 


SERVICE  CALL 


READ  TERMINAL 


Function: 

Read  the  next  available  character  from  the  user'-, 
terminal  . 

Argument  s t 
FID  = 9 

PARW  = none  reauired 
Description: 

This  service  call  passes  the  next  available  ASCII 
character  from  the  user's  terminal  display  buffer  to  the 
user  program.  The  maximum  siz®  input  line  is  SI? 
characters.  Fach  input  line  is  terminated  by  a carries® 
r®turn.  It  is  not  necessary  for  user  proorams  to  echo 
input  characters  since  they  are  already  displayed  on  tn® 
user's  terminal  before  becoming  available  t0  the  user 
prooram.  Line  editino  ^unctions  are  provided  by  '-‘T5. 


Value: 

A single  ASCII  character  - the  end  of  each  inrut  line  is 
indicated  by  the  return  of  a camiaqe  return  (ASCII  = 
ODH)  . 


SERVICE  CALL 


wPITE  TERMINAL 


Function: 

To  write  a character  to  the  user's  terminal. 

A r qume  n 1st 

FID  = 10 

I 

PARM  - a sinqle  ASCII  character 
Oescriotion: 

This  service  call  passes  trie  specified  character  from 
the  user  o r o q r a m to  the  terminal  disDlay  buffer  for 
disolay.  Carriaqe  return  (ASCTI  = ODH)  returns  the 
cursor  to  first  ocsition  of  the  current  line.  Line  Feed 
(ASCII  = OAH)  moves  f-e  cursor  down  on»  line.  Lac1' 
outcut  line  will  normally  b<“  terminated  by  the  CR-L*1 
c omb i na  t i on . 

Value: 

None  returned. 


SFRVICE  CALL 


SFLECT  DkI'/F 


Func  t i on  : 

Selects  the  virtual  flooov  disk  drive  to  be  used  in 
subsequent  floppy  disk  accesses. 


I A rqument s : 

FID  = 12 

PARV  = drive  number  where  A = l,  ?>  = ? , etc. 

1 

Description: 

This  service  call  selects  one  of  the  eight  virtual 
floppy  disk  drives  available  to  each  user  program  for 
use  in  subsequent  f 1 oroy  disk  accesses.  before  a drive 
can  be  selected*  a virtual  disk  must  be  attached. 

Error  Codes: 

0 - Operation  Successful. 

b - Drive  numoer  specified  is  greater  than  7.  Selected 
drive  is  changed. 


10  - Drive  specified  is  not  in  use.  Indicates  that  no 
virtual  disk  has  been  attached  to  the  specified 
drive.  Selected  drive  is  unchanged. 


SERVICE  CALL 


SfcT  nwft 


Function: 

Sets  the  hase  address  oi  the  1 2 R byte  0 w A butter  to  be 
used  in  subseauent  tloonv  disk  accesses. 

A rqument  s : 

FID  =13 

P A R M = base  address  o t DM  A butter 
Descriot ion: 

The  DMA  butter  required  to  access  a virtual  tlonov  disk 
must  oe  a continuous  block  ot  1 2d  bvtes  located  in  the 
user's  memory  soace»  i.e.  with  base  address  ore  a ter 
than  4000H.  Soecityina  a DMA  address  oreater  than  or 
eoual  to  FFOOH  will  have  unoredictable  results/  but  can 
normally  be  expected  to  cause  a svstem  crash  and 
suoseauent  deletion  ot  the  user's  task  upon  recovery. 

E r r o r Codes : 

0 - Operation  successtul. 

7 - Address  specitied  is  less  than  the  base  ot  user's 
memory  soace.  Current  DMA  address  remains 

unc  hanoed . 
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SFRVICE  CALL  SET  TRACK 


Func t i on : 

Sets  the  floony  disk  track  number  to  be  used  in 
subseauent  virtual  floppy  disk  accesses. 


A rgumen  t s : 

FID  = l a 

PARM  = track  number  - 0 to  25b 


Description: 

This  service  call  sets  the  track  number  to  be  used  in 
subseauent  floopy  disk  accesses.  Values  may  range  from 
0 to  25b.  The  value  cannot  be  validatea  until  it  is 
associated  with  a virtual  floopy  disk  number;  therefore, 
no  validation  is  performed  until  a read  or  write 
operation  is  reauested. 


Value: 

None  returned. 
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SERVICE  CALL  SET  SECTOR 

------------  ---------- 

Function: 

Sets  the  f 1 odd v disk  sector  number  to  be  used  in 
subseauent  virtual  floppy  disk  accesses. 

Argument  s : 

FID  = IS 

PARM  r sector  number  - 1 to  2b 

Description: 

This  service  call  sets  the  sector  number  to  be  used  'in 
subsequent  virtual  floppy  bisk  accesses.  Since  eac  * 
floppy  disk  track  contains  2b  sectors  numbered  from  1 to 
26»  this  value  cannot  be  less  than  1 nor  greater  than 
26. 

Error  Codes: 

0 - Operation  successful. 

7 - Sector  number  specified  is  less  than  1 or  greater 
than  26.  Current  value  of  sector  number  regains 
unchanged. 


SERVICE  CALL 


PE ^ D FLOPPY 


Fund  ion: 

Simulates  reading  a 128  byte  sectnr  from  a floppy  disk. 


Argument  s : 

FID  = 16 

PARW  = none  reguired 


Descriot ion: 

This  service  call  simulates  reading  from  a flonpv  disk 
bv  manning  the  current  o r i v e » fracW  and  sector  nu*D»rs 
into  a mini-disk  address?  reading  the  mini-disk  sector 
into  a buffer?  and  moving  1?8  bytes  from  the  miri-nisk 
buffer  into  the  current  DMA  buffer  in  the  user's  memory 
so ace.  Errors  may  occur  at  two  ooints  in  the  process. 

If  the  calculated  mini-disk  address  tails  outside  the 
bounds  of  the  virtual  disk  file  attached  to  tne 

soecified  virtual  drive#  it  indicates  an  error  in  tne 

specified  track  number.  Errors  m3V  also  occur  aurinn 
mini-disk  read  anc  write  operations.  A user  program 

must  consider  such  hardware  errors  as  i r recoverab 1 e 
since  MTS  provides  insufficient  information  to  determine 
the  cause. 

Error  Codes  : 

0 - Ooeration  successful. 

7 - Calculated  mini-disk  address  out  of  bounds.  Prop* 

able  error  in  specified  track  number. 

8 - Abnormal  completion  status  was  returned  by  the 

mini-disk  controller  following  a read  or  write 
ooerat i on . 


1 US 


# 


SERVICE  CALL 


IV R I T E FLOPPY 


Funct i on  : 

Simulates  writing  a 128  byte  sector  to  a F 1 opry  disk. 


A rgument s : 

FTD  = 17 

P A R V = none  required 


Description: 

This  service  call  simulates  writing  to  a Hodov  cisk  by 
mapoing  the  current  drive#  track,  and  sector  numDers 
into  a mini-disk  address?  reading  the  mini-disk  sector 
into  a buffer:  and  movina  12H  bytes  of  data  f ro”  to® 
current  D w A Buffer  in  the  user's  memory  soace  into  tr. » 
mini-disk  buffer.  Errors  may  occur  a*  two  points  in  the 
process.  If  the  calculated  mini-disk  address  * a 1 1 s 
outside  the  bouncs  of  the  virtual  disk  tile  attached  to 
the  specified  virtual  drive,  it  indicates  an  error  in 
the  specified  track  number.  Errors  mav  also  occur 
during  mjni-aisk  read  and  write  operations.  The  user 
should  interpret  such  hardware  errors  as  inoicatiro  a 
pad  sector  on  the  virtual  f 1 oddv  distc  ana  try  repeating 
the  operation  with  a different  flooov  disk  sector  and 
track  combination. 


Error  Codes: 

0 - Operation  successful. 

7 - Calculated  mini-disk  address  out  of  bounds.  profc* 

able  error  in  specified  track  number. 

8 - Abnormal  completion  status  was  returned  by  the 

mini-disk  controller  following  a read  or  writ® 
ope  rat  ion. 


A 


4.  Calling  Procedure 

All  calls  to  w T S * whether  system  calls  or  service 
calls*  are  made  through  a s i n a 1 e entry  Doint  at  location 
2000H.  Each  call  takes  two  arauments:  the  function 

identifier  in  register  C;  and  a oarameter  value  or  address 
in  register  pair  DE.  In  those  cases  where  the  second 
argument  is  only  a single  byte  the  contents  of  the  n 
register  are  ignored. 

Each  call  to  WTS  returns  a value  in  the  A reoistar. 
This  value  mav  be  an  error  code*  an  ASCII  character  coc°*  or 
zero.  The  value  zero  is  returned  by  those  routines  whose 
value  has  no  significance  such  as  WHITE  TERMINAL  or  SET 
TRACK. 

Note  that  the  r®qi ster  assinnments  for  arauments  and 
returned  values  conform  to  the  PL/M  convention  for  passim 
parameters.  The  followino  examples  illustrate  the  cal  lino 
procedure  for  0 08  0 Assembly  Lanauaae*  ML  B 0 * and  PL/M  in  the 
MTS  environment.  Each  example  illustrates  the  seauence 
required  to  read  f 1 copy  disk  sector  22*  track  ^3  on  drive  2 
into  a DMA  buffer  at  address  0100H. 

a.  8080  Assembly  Lanauaae 

When  writina  in  8080  assembly  1 anquace  M T S is 
accessed  by  a direct  call  to  the  VTS  entrv  point: 

MTS  EQU  2000H 


;pid  = 12 

* PR  I VE  NR  = 2 
l«7 


1 


MVT 
M V I 


C,  12 
E * 2 


J 


1 


CALL 

MTS 

; SELECT  DRIVE 

MV  I 

C,  13 

; F 1 0 = 13 

L X I 

D,«100H 

; DM  A ADORFSS  = illOUH 

CALL 

MTS 

;SET  DMA 

MV  T 

C.  14 

; F I D = la 

M V T 

E,u3 

; TR  AC  K NR  = a3 

call 

MTS 

;SET  TRACK 

MV  T 

C,  15 

;FID  = is 

MV  T 

E > 22 

;SECTOR  nr  = 22 

CALL 

MTS 

;SET  SECTOR 

M V I 

C,  16 

;fid  = 16 

CALL 

• 

MTS 

;read  floppy 

• 

• 

MV  I 

c , is 

;fid  = is 

MV  I 

E,23 

;CHANOE  SFCTOR  NP 

CALL 

MTS 

;SET  SECTOR 

MW  I 

C,  16 

;fid  = 16 

CALL 

MTS 

; RE  AD  again 

ML  8 0 

The  r^adiM ' i f v of  m l 8 0 source  oroarams  *ay  be 
enhanced  bv  d e f i n i n q an  M 8 0 macro  for  each  call  to  MTS  used 
in  the  oroarar.  The  followino  code  sequent  contains  severa1 
e *a»c 1 es  . 


[MACRO  mts  ' 2000H  ' ] 

[MACRO  SELECTSDRIVE  OMR  1 

C = IP;  E = [OMR] ; CALL  [MTS] ’ ] 
[MACRO  SETSDMA  DMA  ' 

C = 13;  OE  = [DMA] ; CALL  f MTS1  *1 
[MACRO  SETSTRACK  TNR  ' 

c = i a ; E = it  nr ] ; call  [mtsi  ’ ] 

[MACRO  SETSSECTOR  SMR  • 

C = IS;  E = [SNR] ; CALL  [MTS] ' 1 
[MACRO  READSFLOPPY  ' 

C = 16;  CALL  f MTS]  ' 1 


/*  SPECTFY  COMPLETE  SFCTOR  ADDRESS  AND  DM  A P uF  F F R */ 
[SELECTSDRIVE  •?•]; 

(SETSDMA  ' a 1 00H • ] ; 

[SETSTRACK  • a 3 ' T ; 

[SETiSECTOR  ' 22 • ] ; 

[REAOSFLOPPY] ; 


1 U 8 


r 


/*  INCREMENT  SECTOR  NR  AND  READ  AGAIN  */ 
CSETSSECTOR  ’ 21 ' ] ; 

(OEAD'FLOPPYJ ; 


PL/M 


/a*!!***.**********************************************/ 

/*/  SAMPLE  PL/P  PROGRAM  SEGMENT  */ 

/****************************************************/ 


4000H : 

USER:  PROCEDURE; 


DECLARE 

LIT 

LITERALLY 

'LITERALLY  ' 

MTS 

LIT 

' ?0OQH • , 

SELECTSORTVF 

LIT 

' 1?'  , 

SE  T TDM A 

t.  IT 

'13', 

SETTTRACK 

LIT 

'14', 

SETSSECTOR 

LIT 

•15', 

PEA  0 iFLOPD  Y 

LIT 

' 16'  , 

DISPLAYSMSG 

LIT 

' l ' ; 

/***********■***■**************■»********  + ****+*■»***  + + ***/ 
/*  MTS  INTERFACE  PROCEDURES  */ 

/♦a***************************************************/ 

MTSl:  PROCEDURE  (F10,PARM); 

/♦a**********************************/ 

/*  PROVIDES  THE  MTS  INTERFACE  FOR  */ 

/*  FUNCTIONS  fc'HTCH  00  NOT  REQUIRE  A */ 

/*  RETURN  VALUE.  */ 

/*  TNPUT:  FID  - MTS  FUNCTION  ID  */ 

/*  PARM  - PARAVFTER  OR  ADDRESS*/ 

/*  OF  PARAMETER  LIST.  */ 

/************************************/ 

DECLARE  FID  BYTE,  PARM  ADDRESS; 

GO  TO  MTS; 

END  MTSl,* 


MTS2 ; PROCEDURE  (FID.papm)  BYTE; 

/************************************/ 
/*  PROVIDES  THE  "MTS  INTERFACE  FOR  */ 
/*  FUNCTIONS  WHICH  REGUTRE  A VALUE  */ 
/*  RETURNED.  INPUT  PARAMETERS  APE  */ 
/*  THE  SAME  AS  IN  MTSl.  */ 

/ft***********************************/ 

DECLARE  FID  BYTE,  PARM  ADDRESS; 

GO  TO  MTS; 

END  MTS?; 


/♦A****************************************-**********/ 

/*  SPECIFY  COMPLF  TF  SECTOR  AODRESS  AND  DWA  BIIFFEP  */ 

/a***************************************************/ 

call  MTS1 (SELFCTSORIVE,  2); 
call  vtsi  iset'BDma,  mnon); 

CALL  MTS1 (SFTSTRACK,  A3); 
call  MTS1 (SETSSFCTGP,  2?); 

/a************************************************* 

/*  PEAD  FLOPPY  RETURNS  AN  ERROR  CODE  WHICH  ILL 
/*  PE  RETURNED  TO  MTS  TO  PE  DISPLAYED  ON  ThF 
/*  TERMINAL  STATUS  LINE. 

/a************************************************* 

CALL  vrsi fDISPLA YtMSG,  MTS2fRFAD$ FLOPPY >0)  ) ; 


/*  INCREMFNT  SECTOR  NR  AND  READ  AGAIN  * / 

CALL  MTS1  (SETTSECTOR,  21,); 

CALL  MTS1 (DISPLAYS MSG,  M T 5 2 ( R F A D *F LPP° Y , 0 ))  ; 


* * / 
* / 
+ / 
* / 
* * / 


END  USEP; 
EOF 


1E0 


MTS  was  designed  to  provide  each  user  with  his  own 
virtual  «0fl0  mi  c coprocessor . Unfortunately*  the 

architecture  of  the  POBO  CPU  is  not  amenable  to  self- 
virtualization. As  a conseouence  several  limitations  must 
be  imoosed  on  user  programs  runnina  in  the  MTS  environment. 
These  limitations  are: 

(1)  The  user's  memory  snace  extends  from  aciriress  4 0 h 0 H to 
FEFF,  a total  of  4 0 , p Q b bvtes.  All  user  code,  data* 
ana  buffers  must  be  contained  within  this  area  of 
memory  . 

(2)  All  u s e r -de f i nee  stacks  must  he  four  bytes  lonqer  tKan 
the  maximum  size  renuired  bv  the  user.  The  four  *>  x t r a 
bytes  are  needeo  if  an  interrupt  occurs  while  the 
user's  stack  is  full.  Failure  to  provide  this 
additional  space  mav  result  in  ranoom  execution  errors 
which  are  not  reproducible  and  extremely  difficult  to 
d i agnose . 

(3)  User  programs  should  not  read  or  write  directly  to  I/O 
ports  while  runninq  under  M T S . Terminal  ana  flonpv 
disk  access  is  provided  by  MTS  service  calls. 
Attempts  to  interface  directly  with  the  Sycor  '440 
peripherals  or  auxiliary  storage  devices  may  interfere 
with  the  operation  of  MTS  ana  damaae  other  users. 
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MTS  PROGRAM  LISTINGS 


/******************************************************/ 
/*  GLOBAL  IDENTIFIERS  */ 

/******************************************************/ 


S* 
/* 
/* 
/* 
/* 
/* 
/* 
s* 
/* 
/* 
/* 
/* 
/* 
/* 
s* 
/* 
/* 
/* 
/* 
/* 
s * 
/* 
/* 
/* 
/* 
/* 
/*. 
s * 
/* 
/* 
/* 
/* 
/* 
/* 
s* 
/* 
/* 
/* 
/* 
/* 
s* 
/* 
/* 
/* 
/* 
/* 
/% 
s* 
s * 
s * 
/* 
/* 
/* 
s* 
s * 
/* 
/* 
/* 


/* 
s * 
/* 

/* 


*s 

THE  FOLLOWING  DECLARATIONS  DEFINE  SYSTEM  I DENT I-  */ 
FIERS  WHOSE  SCOPE  IS  GLOBAL  THROUGHOUT  MTS.  THESE  */ 
IDENTIFIERS  MAY  BE  DIVIDED  INTO  THREE  DISTINCT  */ 
GROUPS.  TIIE  FIRST  GROUP  INCLUDES  ANY  IDENTIFIER  */ 
CONSIDERED  CLOBAL  BECAUSE  IT  IS  REFERENCED  IN  TWO  */ 
OR  MORE  MODULES  OF  THE  MTS  ML80  SOURCE  PROGRAM.  BY  */ 
INCLUDING  THE  DECLARATIONS  FOR  ALL  SUCH  IDENTIFIERS*/ 
IN  A SINGLE  MODULE,  INTERMODULE  LINKAGE  IS  GREATLY  */ 
SIMPLIFIED,  AND  THE  SOURCE  PROGRAMS* S READABILITY  */ 
AND  CLARITY  ARE  IMPROVED.  */ 

*/ 

THE  SECOND  GROUP  OF  IDENTIFIERS  INCLUDES  THOSE  */ 
VARIA3LES  WHICH,  TAKEN  TOGETHER,  DEFINE  TIIE  STATE  */ 
OF  THE  SYSTEM,  I.E.  THE  SYSTEM  STATE  BLOCK.  THE  */ 
CONCEPT  OF  SYSTEM  STATE  IS  IMPORTANT  IN  MTS  BECAUSE*/ 
THE  SYCOR  440  HARDWARE  ARCHITECTURE  PROVIDES  NO  */ 
PROTECTION  AGAINST  INADVERTENT  OR  MALICIOUS  TAMP-  */ 
ERIHC  WITH  SYSTEM  CODE  BY  USER  PROGRAMS.  TO  MINI-  */ 
MIZE  THE  EFFECTS  OF  SYSTEM  CRASHES  CAUSED  BY  SUCH  */ 
TAMPERING  MTS  PROVIDES  A LIMITED  RECOVERY  CAPABIL-  */ 


ITY.  AFTER  A TASK'S  TIMESLICE  EXPIRES,  AND  JUST  */ 
PRIOR  TO  INITIATING  A NEW  TASK,  THE  MTS  MONITOR  */ 
COPIES  THE  CONTENTS  OF  THE  SYSTEM  STATE  BLOCK  TO  A */ 
FILE  NAMED  . MTSRCVR.  IF  A CRASH  OCCURS  WHILE  THE  */ 
NEW  TASK  IS  EXECUTING.  RECOVERY  MAY  BE  ACCOMPLISHED*/ 
BY  REBOOTING  MTS  AND  READ  INC  THE  CONTENTS  OF  */ 
• MTSRCVR  DACK  INTO  THE  SYSTEM  STATE  BLOCK.  THE  */ 
TASK  WHICH  CAUSED  THE  CRASH  IS  THEN  DELETED  AND  */ 
NORMAL  OPERATION  CONTINUES.  */ 

*/ 


THE  THIRD  AND  FINAL  GROUP  OF  IDENTIFIERS  INCLUDES  */ 
SYSTEM  DATA  ASSOCIATED  WITH  A PARTICULAR  USER  TASK. */ 
SINCE  THIS  DATA  IS  ONLY  USED  WHEN  ITS  ASSOCIATED  */ 
TASK  IS  ACTIVE,  THE  SPACE  REQUIRED  FORMS  A SYSTEM  */ 
AREA  IN  THE  TASK'S  SWAP  IMAGE.  THIS  DATA  IS  SWAPPED*/ 


IN  AND  OUT  ALONC  WITH  THE  USER  AREA  OF  THE  SWAP  */ 
IMAGE. 

*/ 

THE  THREE  PRIMARY  IDENTIFIER  GROUPS  DESCRIBED  */ 

ABOVE  MAY  ALSO  BE  SUBDIVIDED  BASED  ON  USAGE  AND  */ 

STORAGE  ALLOCATION  REQUIREMENTS.  THE  GROUP  AND  */ 

SUBGROUP  HEADINCS  FOR  DECLARATIONS  IN  THIS  MODULE  */ 
ARE  AS  FOLLOWS:  */ 

*/ 

A.  GENERAL  SYSTEM  DECLARATIONS  */ 

B.  SYSTEM  STATE  BLOCK  DECLARATIONS  */ 

1 . SYSTEM  CONTROL  */ 

2.  TASK  CONTROL  TABLE  */ 

3.  DISK  MAP  TABLE  */ 

C.  SYSTEM  SWAP  AREA  DECLARATIONS  */ 

1.  VIRTUAL  DISK  CONTROL  BLOCK  */ 

2.  SWAP  STACK  */ 

*/ 

THE  ORDER  OF  ALL  DECLARATIONS  IN  THIS  MODULE  MUST  */ 
BE  MA INTA I NED  TO  PRODUCE  A PROPERLY  FORMATTED  */ 

OBJECT  MODULE.  IN  TniS  REGARD  SPECIFICATION  OF  THE  */ 
INITIAL,  ATTRIBUTE  IN  A DECLARATION  MUST  BE  CONS  ID-  */ 
ERED  CAREFULLY  SINCE  THE  ML80  COMPILER  ALLOCATES  */ 
DIFFERENT  AREAS  OF  MEMORY  FOR  INITIALIZED  AND  */ 

UNINITIALIZED  VARIABLES.  SPECIAL  PRECAUTIONS  ARE  */ 
ALSO  NECESSARY  FOR  LOCAL  VARIABLES  USED  ONLY  IN  */ 
SINGLE  MODULES.  THE  ML80  LINK  EDITOR  IS  FORCED  TO  */ 
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A 


/*  ALLOCATE  SPACE  FOR  SUCH  VARIABLES  WITHIN  TOE  */ 
/*  MODULE’S  CODE  AREA  BY  DECLARING  EACH  SUCH  VARIABLE  */ 
/*  WITH  TYPE  DATA.  THIS  TECHNIQUES  IMPOSES  A PENALTY  */ 
/*  OF  THREE  BYTES  PER  DECLARATION  FOR  UNNECESSARY  */ 
/*  JUMP  INSTRUCTIONS,  BUT  TOE  SIMPLIFICATION  OF  */ 
/*  INTERMODULE  LINKAGES  MAKES  THE  TRADEOFF  WORTHWHILE.*/ 
/*  */ 


/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXy 
/-XXXXXXXXXXXXXXXXXXXXXXXXXXX'i :XXXXXXXXXXXXX*XXXXXXXXXXXX/' 


/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXS 

yxxxxxxxxxxxx  GENERAL  SYSTEM  DECLARATIONS  xxxxxxxxxxxxxy 
/xxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxy 


DECLARE  PAR!1(2>  BYTE  INITIAL  (0,0); 

DECLARE  DISK  BYTE  INITIAL  (0); 

DECLARE  DRIVE  BYTE  INITIAL  (0); 

DECLARE  ERROR  BYTE  INITIAL  (0); 

DECLARE  LOCK  BYTE  INITIAL  (1); 

/*  SYSTEM  LOCK  — 

/*  BIT  0:  SWAP  LOCK  - MTS  CODE  EXECUTING 
/x  BIT  is  SPOOL  LOCK  - SPOOLING  UNDER 
/*  INTERRUPT  CONTROL 

/*  BITS  2-7:  (NOT  USED) 

DECLARE  TASK8TIHER  BYTE  INITIAL  (OEFH); 

/*  COUNTER  RECORDING  HOW  MANY  TIMER  INCREMENTS 
/*  ( 50MS)  REMAIN  IN  TIMESLICE 
DECLARE  SVC3STACKC 20)  BYTE  INITIAL  (0); 

/*  SERVICE  MODULE  STACK  */ 

DECLARE  SYSSSTACKC  20)  BYTE  INITIAL  (0); 

/*  MONITOR  MODULE  STACK  */ 

DECLARE  MDBUF( 5 12)  BYTE  INITIAL  (0); 

/*  MINI-DISK  BUFFER  - CONTAINS  ONE  SECTOR  */ 
DECLARE  MBS  AD( 2)  BYTE  INITIAL  (0,0); 

/*  SECTOR  NUMBER  OF  DATA  CONTAINED  IN  MDBUr  */ 


*/ 

*/ 

*/ 

*/ 

X/ 


x/ 

X/ 


/XXXXXXXXXXXX-XXX-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/ 

sxxxxxxxxxx  SYSTEM  STATE  BLOCK  DECLARATIONS  xxxxxxxxxxx/ 

/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXS 


^xxxxxxxxxxxxxxxxxxx  SYSTEM  CONTROL  xxxxxxxxxxxxxxxxxxx/ 

DECLARE  TASK  BYTE  INITIAL  (0); 

/*  TERMINAL  NR  OF  TASK  CURRENTLY  ALLOCATED  */ 

/*  TOE  CPU  - RANGE  0-U  */ 

DECLARE  RF.CSF  I LE(  2)  BYTE  INITIAL  (0,0); 

/*  MIN I -DISK  SECTOR  NUMBER  OF  . MTSRCVR  */ 

DECLARE  CNFCSF  ILE(  2)  BYTE  INITIAL  (0,0); 

/*  MINI-DISK  SECTOR  NUMBER  OF  . MTSCNFG  */ 

yxxxxxxxxxxxxxxxxx  TASK  CONTROL  TABLE  *****************/ 
/*  THE  TCT  CONTAINS  INFORMATION  ON  THE  STATE  OF  EACH  */ 
/*  TASK  AND  DATA  REQUIRED  TO  SUPPORT  SWAPPING.  EACH  x/ 

/x  VARIABLE  CONTAINS  FOUR  ENTRIES  - ONE  FOR  EACH  OF  */ 

/*  THE  FOUR  TERMINAL  TASKS.  */ 

/S***********:!::t:**:***:):**tt*****:*:.,::*:r:********************;f:*/ 

DECLARE  TCTSSTATOS( 4)  BYTE  INITIAL  (0,0. 0,0); 


/% 

BIT 

0: 

SIMULATE  BOOTSTRAP  DURING  NEXT 

*/ 

/% 

TIMESLICE 

/% 

BIT 

1 : 

CALL  MCP  DURINC  NEXT  TIMESLICE 

*/ 

/* 

BIT 

2: 

(RESERVED  FOR  CASSETTE) 

*/ 

/% 

BIT 

O • 
U • 

(RESERVED  FOR  ASYNC) 

/* 

BIT 

4: 

BLOCKED  FOR  PRINTER  I/O 

*/ 

/% 

BIT 

5: 

BLOCKED  FOR  TERMINAL  I/O 

*/ 

/% 

BIT 

6: 

CURRENT  SWAP  IMAGE  RESIDES  ON 

*/ 

/* 

MINI-DISK 

*/ 

/* 

BIT 

7: 

CURRENT  SWA?  I MAGE  IN  MEMORY 

*/ 
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DECLARE  TCT3DM(  32)  BYTE  INITIAL  ( OCOR, 0 , 0 , 0 , 0 , 0 , 0 , 0 , 

OCOH ,0,0, 0,0, 0,0,0, OCOR ,0,0, 0,0, 0,0,0, 

OCOR, 0,0, 0.0, 0,0,0)  ! 

/*  DRIVE  MAP  - POINTERS  TO  VIRTUAL  DISK  ASSOC-  */ 

/*  IATED  WITH  EACH  VIRTUAL  DRIVE.  BYTES  0-7  */ 

/*  CORRESPOND  RESPECTIVELY  TO  DRIVES  A-H  FOR  */ 

/*  EACH  8 BYTE  ENTRY.  */ 

/*  BITS  0-4:  DISK  NR  - RANGE  0-31  */ 

/*  BIT  5:  (NOT  USED)  */ 

/*  BIT  6:  READ  ONLY  FLAG  */ 

/*  BIT  7:  IN  USE  FLAG  */ 

DECLARE  TCTSS IZE( 4)  BYTE  INITIAL  (32,32,32,32): 

/*  SIZE  OF  SWAP  IMAGE  EXPRESSED  IN  NUMBER  */ 

/*  OF  312  BYTE  MINI-DISK  SECTORS  */ 

DECLARE  TCT3B0F.(  8)  BYTE  INITIAL  ( 0 , 0, 0 , 0 , 0 , 0, 0 , 0)  ; 
DECLARE  TCTSEOE(B)  BYTE  INITIAL  ( 0, 0 , 0 , 0 , 0 , 0 , 0 , 0) ; 

/*  MIN  I -DISK  SECTOR  NUMBER  FOR  EACH  SWAP  FILE  */ 

/*  - INITIALIZED  WHEN  NTS  LOADED  */ 

/*******************  DISK  MAP  TABLE  a*!***:::*************/ 
/*  THE  DMT  CONTAINS  INFORMATION  ON  THE  STATUS,  PRO-  */ 
/'*  TECTION,  AND  LOCATION  ON  THE  MINI-DISK  OF  ALL  VIR-  */ 
/*  TU.AL  FLOPPY  DISKS.  EACH  VARIABLE  CONTAINS  32  */ 

/*  ENTRIES  - ONE  FOR  EACH  POTENTIAL  DISK  NR.  THE  */ 

/*  ENTIRE  TABLE  IS  LOADED  AND  VERIFIED  DURING  MTS  */ 
/*  INITIALIZATION.  */ 

/•******#:jc***********:fc*****:|:#*:**********:#***:|c*****:f:*****/' 


DECLARE  DMT3FLAG( 32)  BYTE  INITIAL  ( 0, 0 , 0, 0, 0, 0 , 0, 0, 0 . 0 , 


0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0.0, 0,0, 0,0, 0,0, 0,0); 


/* 

BIT 

0: 

DISK  EXISTS 

Jr/ 

/'Jr- 

BIT 

1 : 

IN  USE 

Jr/ 

/'Jr. 

BIT 

2: 

PROTECTED  - KEY  REQUIRED 

Jr/ 

/Jr 

BIT 

3: 

RESTRICTED  TO  RE/AD  ONLY  W/0  KEY 

Jr/ 

/■* 

BITS  4- 

•7 : ( NOT  USED) 

Jr/ 

DECLARE  DMTSBOE(  64)  BYTE  INITIAL  ( 0 . 0 , 0 , 0 , 0 . 0 , 0 , 0, O , 
0,0, 0.0. 0,0, 0,0, 0.0, 0.0, 0,0, 0,0, 0,0, 0,0, 0.0, 0,0, 
0,0, 0,0, 0,0, 0,0, 0,0, 0,0. 0,0, 0,0, 0,0, 0,0. 0,0, 0,0, 
0,0, 0,0. 0,0,0) ; 

/*  MINI-DISK  SECTOR  NUMBER  FOR  BEGINNING  */ 

/:(-•  OF  EXTENT  *✓ 

DECLARE  DMTSF.OE(  64)  BYTE  INITIAL  ( 0 , 0 , 0 . 0 , 0 , 0 , 0 , 0 , 0, 
0,0, 0,0, 0,0. 0,0, 0,0, 0,0. 0,0, 0,0, 0,0. 0,0, 0,0, 0,0, 
0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0.0, 
0,0, 0,0, 0,0,0) ; 

/*  MINI-DISK  SECTOR  NUMBER  FOR  END  */ 

/*  OF  EXTENT  */ 

DECLARE  DMT3KEY(  128)  BYTE  INITIAL  (20H); 

/*  ONE  TO  FOUR  ASCII  CHAR  PROTECTION  KEY  */ 


/St******************:.!:'*****:):****:.':  .***********************/ 

/* **********  SYSTEM  SWAP  AREA  DECL ARAT IONS  ************/ 
/*********************************.?:********************/ 


/*************  VIRTUAL  DISK  CONTROL  BLOCK  *************/ 
/*  EACH  USER  TASK  HAS  AVAILABLE  8 VIRTUAL  DRIVES  WHICH*/ 
/*  MAY  BE  SELECTED  TO  ACCESS  THE  ATTACHED  VIRTUAL  */ 
/*  DISK.  FOR  EACH  USER  IT  IS  NECESSARY  TO  RECORD  */ 
/*  WHICH  DRIVE  IS  CURRENTLY  ACTIVE,  AND  ADDITIONAL  */ 
/*  DATA  NEEDED  TO  MAP  A VIRTUAL  DISK  ACCESS  INTO  A */ 
/*  PHYSICAL  MINI-DISK  ACCESS.  ALL  THIS  INFORMATION  IS  */ 
/*  MAINTAINED  IN  THE  VDC  BLOCK.  THE  VDC  BLOCK  ASSOC-  */ 
/*  IATED  WITH  EACH  TASK  IS  CONTAINED  IN  THAT  TASKS  */ 
/*  SWAP  FILE  IN  A SPECIAL  AREA  RESERVED  FOR  MTS  SYS-  */ 
/*  TEM  USE.  THIS  MEANS  THAT  ONLY  ONE  OF  THE  FOUR  VDC  */ 
/*  BLOCKS  MAINTAINED  BY  THE  SYSTEM  IS  EVER  RESIDENT  */ 
/*  IN  MEMORY  AT  ANY  ONE  TIME.  */ 

,/********:!.-****:f:****:K:lc*****:f.-*****:;:****************:i!*****/' 


DECLARE  VDCSDRI VE  BYTE: 
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/* 

BITS  0- 

■2:  DRIVE  NR  FOR  DRIVE  CURRENTLY 

*/ 

/* 

SELECTED 

*/ 

/* 

B ITS  3- 

•5 : ( NOT  USED) 

*/ 

/* 

BIT  6: 

READ  ONLY  FLAG 

*/ 

/% 

BIT  7: 

MODIFICATION  FLAG  - SET  WHEN  CON- 

*/ 

/% 

TENTS  OF  BUFFER  MODIFIED 

*/ 

DECLARE  VDCSBOF.I 2)  BYTE: 

/*  MINI-DISK  SECTOR  NUMBER  FOR  BOE  OF  VIRTUAL  */ 
/*  DISK  CURRENTLY  ATTACHED  TO  SELECTED  DRIVE  */ 
DECLARE  VDCSE0EI2)  BYTE: 

/*  MINI-DISK  SECTOR  NUMBER  FOR  EOE  OF  VIRTUAL  */ 
/*  DISK  CURRENTLY  ATTACHED  TO  SELECTED  DRIVE  */ 
DECLARE  VDC3SECT0R  BYTE; 

VIRTUAL  DISK  SECTOR  NR  FOR  SUBSEQUENT  */ 

/*  ACCESSES  - RANGE  1-26  */ 

DECLARE  VDCSTRACK  BYTE; 

/*  VIRTUAL  DISK  TRACK  NR  FOR  SUBSEQUENT  */ 

/*  ACCESSES  - RANGE  0-76  */ 

DECLARE  VDCSDMA<2)  BYTE; 

/*  MEMORY  ADDRESS  OF  128  BYTE  DMA  BUFFER  */ 

/*  FOR  SUBSEQUENT  VIRTUAL  DISK  ACCESSES  */ 

SWAP  STACK 


/*  EACH  TIME  A TASK  IS  SWAPPED  OUT  THE  CURRENT  GPER- 
/*  ATING  ENVIRONMENT,  I.E.  PSN,  BC,  DF,,  IIL.  AND  SP, 

/*  MUST  BE  SAVED  IN  A KNOWN  AREA  SO  THAT  IT  CAN  BE  */ 

/*  QUICKLY  RESTORED  WHEN  THE  TASK  IS  SWAPPED  BACK  IN.  */ 

/*  MTS  USES  A STACK  IN  THE  SYSTEM  AREA  OF  TIIE  SWAP  */ 

1 MAGE  TO  HOLD  THE  ENVIRONMENT  WHEN  A TASK  IS  */ 

/*  INACTIVE.  #/ 


DECLARE  SWAPSSTACKI 10)  BYTE; 

/*  AREA  IN  WHICH  USER  ENVIRONMENT  IS  */ 
/%  SAVED  WHEN  TASK  IS  SWAPPED  OUT  */ 

EOF 


k 


/******************************************************/ 


/*  INTERRUPT  MODULE  */ 

/'*****:S**#************:):*******************#:i;:fc**:t:**:f::t:***/ 
/*  */ 

/*  *s 

/*  ALL  HARDWARE  INTERRUPTS  ON  THE  SYCOR  440  SYSTEM  */ 
/*  CAUSE  THE  EXECUTION  OF  A RST  1 INSTRUCTION.  THIS  */ 

/*  INSTRUCTION  BEHAVES  LIKE  A CALL  TO  LOCATION  0008H,  */ 
/*  I.E.  TIIE  PC  VALUE  IS  STACKED,  AND  CONTROL  TRANS-  */ 
/*  FERRED  TO  LOCATION  0008II.  DUE  TO  THIS  HARDWARE  */ 

/*  CHARACTERISTIC,  THE  USER  MUST  ENSURE  THAT  ANY  USER  */ 
DEFINED  STACKS  ARE  AT  LEAST  FOUR  BYTES  LARGER  THAN 
/-*  THE  MAXIMUM  SIZE  REQUIRED  BY  THE  USER’S  OWN  CODE.  *■/ 
/*  SINCE  ALL  PERIPHERAL  DEVICES  CAUSE  EXECUTION  OF  */ 
/*  THE  SAME  INTERRUPT  INSTRUCTION.  SOME  MEANS  MUST  BE  */ 
/*  AVAILABLE  TO  DISTINGUISH  BETWEEN  DEVICES  WHENEVER  */ 

/*  AN  INTERRUPT  OCCURS.  THE  SYCOR  440  SOLVES  THIS 
s*  PROBLEM  BY  DEFINING  AN  INTERRUPT  LEV'LL  FOR  EACn 
/*  DIFFERENT  DEVICE.  THERE  ARE  17  INTERRUPT  LEVELS  */ 
/*  WITH  VALUES  RANGING  FROM  0 TO  16.  A HIGHER  NUMERIC  */ 
/*  VALUE  ALSO  IMPLIES  A HIGHER  PRIORITY  FOR  THE  */ 

/*  ASSOCIATED  DEVICE.  WHEN  AN  INTERRUPT  OCCURS  THE  *V 

/*  LEVEL  IS  AVAILABLE  ON  INPUT  LATCH  0.  SIMULTANEOUS  */ 

/*  INTERRUPTS  WILL  BE  INPUT  SEQUENTIALLY  IN  PRIORITY,  */ 

/w  I.E.  DESCENDING,  SEQUENCE  BY  LEVEL  NUMBER.  WHEN 
/*  THE  LEVEL  READS  ZERO  ALL  PENDING  INTERRUPTS  HAVE  */ 
/*  BEEN  PROCESSED.  THE  INTERRUPT  LEVEL  ASSIGNMENTS  */ 
/*  WHICH  APPLY  TO  THE  CURRENT  NP3  SYCOR  440  HARDWARE  */ 
CONF I CURAT I ON  ARE  AS  FOLLOWS:  */ 

/*  */ 

/*  LEVEL  DEVICE  */ 



/*  16  DEBUGGER  */ 

/*  15  POWER  FAIL  */ 

/*  14  PARITY  CONTROL  */ 

/*■  1 1 ASYNC  COMM  */ 

/*  10  TERMINAL  CROUP  0 */ 

O TIMER  *■/ 

6 PRINTER  0 */ 

/*  2 FLOPPY  DISK  */ 

/ I CASSETTE  */ 

/% 

/*  THIS  MODULE  CONTAINS  THE  CODE  USED  BY  MTS  TO  PRO-  */ 
/*  CESS  INTERRUPTS.  THIS  CODE  CONSISTS  OF  AN  INTER-  */ 
/*  RUPT  CONTROLLER  PLUS  A SET  OF  INTERRUPT  HANDLER 
/*  ROUTINES  - ONE  ROUTINE  FOR  EACH  DEVICE.  THE  INTER-  */ 
/*  RUPT  CONTROLLER  SAVES  THE  CURRENT  ENVIRONMENT.  */ 

/*  IDENTIFIES  THE  INTERRUPT  LEVEL,  CALLS  THE  APPROP-  */ 
/*  RIATE  HANDLER  ROUTINE,  AND  THEN  RESTORES  THE  */ 

/*  ENV I RONMENT  BEFORE  RETURNING  TO  THE  INTERRUPTED  */ 
/*  PROGRAM.  THE  HANDLER  ROUTINES  ARE  TAILORED  TO  THE  */ 
SPECIFIC  REQUIREMENTS  OF  DIFFERENT  DEVICES.  IN 
/*  ORDER  TO  UTILIZE  THE  CODE  CONTAINED  IN  THE  INTER-  */ 
/*  RUPT  MODULE  IT  IS  NECESSARY  FOR  THE  MTS  INITIAL-  */ 
/*  IZATION  ROUTINE  TO  LOAD  A JUMP  TO  THE  INTERRUPT  */ 
/*  CONTROLLER  IN  MEMORY  LOCATIONS  0008- 000 AH.  */ 

/*  */ 

/■* 


/*********$**:f;***:t:***:t:*******:ic**:.':»******:*::t::s**:<:**:f:l:**:t:**/' 
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/************  INTERRUPT  PROCESSING  MACROS  ************** 

[ MACRO  LEVEL  ’ IN(O)  ’ 1 
[MACRO  DEBUGSLATCH  ’ OFFH’ I 
[MACRO  CSSTSLATCII  ’85 II’] 

[MACRO  PRINTER3LATCII  *8AH’I 
[ MACRO  TIMERS  LATCH  ’0211’  ] 

[ MACHO  TERM I N ALSL ATC H ’ 3EH' ] 

[ MACRO  MATR I X3 LATCH  ’ 3FH’ ] 

[MACRO  I NTSPEND INC  ’ ( A=  [ LEVEL]  A)  'ZERO’] 

[MACRO  DEBUGS  I NTSPEND I NG  ’ ( A= [ LEVEL] j A::16)  ZERO’] 

yxx:te********X*X**  MODULE  DECLARATIONS  ans:****:}:**********/' 

[ INT  TOP  BLINK  EP]  IBLINK:=4]  [T0P:=30I  [EP:=T0P-10] 
DECLARE  INT3STACK  DATA  ( 0 , 0 , 0 , 0, 0 , 0. 0 , 0, 0 , 0 , 0 , 0 , 0 , 

0,0, 0,0, 0,0, 0,0. 0,0, 0,0, 0.0, 0,0,0); 

DECLARE  BLINKSTIMER  DATA  (1); 

DECLARE  SAVHL  DATA  (0,0); 


/'Sc#* PROCEDURES  i***#*:.1:*:):*******:.1:*****/ 


DUMMYSHDLR:  PROCEDURE; 

/**:(;*****»:**«»***********»!  j):***;,':***********.-*  a:**********/ 


/*  THIS  PROCEDURE  PROVIDES  A COMMON  EMPTY  INTERRUPT  */ 

/*  HANDLER  FOR  THOSE  INTERRUPT  LEVELS  WHICH  SHOULD  */ 

/*  NEVER  OCCUR  WITH  THE  CURRENT  NPS  SYCOR  440  ILYRD-  */ 

/*  WARE  CONFIGURATION.  ITS  ONLY  ACTION  IS  AN  IMMEDI-  */ 

/*  ATE  RETURN.  */ 

CALLED  BY:  I NTERRUPTSCONTROL.LER  */ 


/XXXXXXXX :'K  :K  X 3:  :i:  X '!'  X :j: X X * 3:  * X X X '< X X X.XXXXXrx  X XXX X XXX/ 

RETURN; 

END  DUMNYSHLDR; 


DEBUGS HDLR:  PROCEDURE; 

/**^;»:***^;*********«:f:*S:«****»c***«*****a!*:*»:**“*S:S:*»:******/' 

/*  THIS  HANDLER  IS  INCLUDED  TO  ALLOW  USAGE  OF  THE  */ 

/X  SYCOR  340B  DEBUCGER  IN  THE  SOFT  DEBUG  MODE  WHEN  *s 

/x  RUNNING  UNDER  MTS.  IT  WAS  DISCOVERED  DURING  DEVEL-  */ 
/•*  OPMENT  AND  TESTING  THAT  THE  DEBUGGER  IS  LARGELY  */ 

/*  UNRELIABLE  IN  THE  SOFT  MODE.  THIS  IS  .APPARENTLY  */ 

/*  DUE  TO  HARDWARE  CHANGES  IN  THE  440  SYSTEM  MADE  */ 

/*  AFTER  THE  DEBUGGER  W.AS  DESIGNED.  */ 

/*  CALLED  BY:  INTERRUPTSCONTROLLER  */ 

/*X*XXXXXXXXXXXXXXXX*XXXXXXXXXXXXXXXXXXXX*XXXX*XXXXXXXX/ 

/*  DISPLAY  ENVIRONMENT  ON  DEBUGGER  */ 

HL=2+SP: 

M(6H)  = (A=L);  M(7H)  = (A=H); 

/*  ACKNOWLEDGE  DEBUG  INTERRUPT  */ 

OUT( [ DEBUGSLATCH] ) = ( A= I ) ; 

/*  CPU  IDLES  WHILE  WAITING  FOR  DEBUGGER  TO  */ 

/*  INITIATE  RESUMPTION  OF  EXECUTION  */ 

DO  WHILE  [ DEBUGS  I NTSPEND I NG] ; 

END: 

END  DEBUG3HDLR; 

CASSETTESHDLR:  PROCEDURE; 

OUT(  [ CSSTSLATCH] ) = ( A= I OH)  ; 

END  CASSETTESUDLR; 

PRINTERSHDLR:  PROCEDURE; 

A=  IN(  [ PR  I h'TERSLATCHl  ) ; 

F.ND  PRINTERSHDLR; 

TIMERSHDLR:  PROCEDURE; 

/'***:**:**:********:J:*:K:t:W*:i:*:t:a:**:)c:t::s:‘::s************:j:***#*****/ 

/*  THE  TIMER  INTERRUPT  HANDLER  MANAGES  THE  TWO  FUNC-  */ 
/*  TIONS  OF  MTS  WHICH  OCCUR  AT  PERIODIC  INTERVALS:  */ 

/x  BLINKING  THE  TERMINAL  CURSORS  AND  RETURNING  CONTROL*/ 
/*  TO  THE  SYSTEM  WHEN  A TASK’S  TIMESLICE  EXPIRES.  IN  */ 
/*  ORDER  TO  KEEP  TPuACK  OF  THE  TWO  INTERVALS  INVOLVED,  */ 
/*  THE  PROCEDURE  MAINTAINS  TWO  COUNTERS.  THESE  COUN-  */ 
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/*  TERS  ARE  EACH  SET  TO  AN  INITIAL  VALUE  AND  THEN  */ 
/*  DECREMENTED  EACH  TIME  A TIMER  INTERRUPT  OCCURS.  */ 
/*  THE  ACTUAL  VALUE  CONTAINED  IN  EITHER  COUNTER  AT  ANY*/ 
/*  INSTANT  REPRESENTS  THE  TIME  REMAINING  IN  THE  INTER-*/ 
/*  VAL  IN  MULTIPLES  Or  50MS  SINCE  THIS  IS  THE  FIXED  */ 
/*  INTERVAL  BETWEEN  TIMER  INTERRUPTS.  WHEN  THE  TASKS  */ 
/*  TIMER  COUNTER  HAS  BEEN  DECREMENTED  TO  ZEr.O,  CONTROL*/ 


/*  IS  TRANSFERRED  TO  THE  MONITOR  WHERE  THE  CURRENT  */ 
/*  TASK  IS  SWAPPED  OUT  AND  A NEW  TASK  SWAPPED  IN.  */ 
/*  WHEN  THE  BLINKSTIMER  COUNTER  REACHES  ZERO  THE  */ 
/*  BLINKSCURSOR  PROCEDURE  IS  CALLED.  IN  EITHER  CASE  */ 
/*  THE  TIMER  HANDLER  RESETS  THE  COUNTER  TO  ITS  IN  IT-  */ 
/*  IAL  VALUE  AND  CONTINUES.  */ 
/*  CALLED  BY:  INTF.RRUPTSCONTROLLER  */ 


/#*****************************************************/ 
TASKST I MER*  ( A=  TASKST I MER- 1 ) : 

BL I NKST I MER=  ( A=  BL I NKST I HER- 1 ) ; 

IK  <A::0)  ZERO  THEN  /*  BLINK  INTERVAL  EXPIRED  */ 

DO; 

CALL  [BLINKSCURSOR]; 

BL I NKST I MER=  ( A=[  BLINK] ) ; 

END: 

OUT( I TIMERSLATCH] ) =( A=C> : /*  RESET  TIMER  */ 

IF  ( A=  TASKST I HER;  A: : 0)  ZERO  THEN 
DO:  /*  TIMESLICE  EXPIRED  */ 

IF  ( A=>  LOCK)  ICY  THEN 

DO;  /*  SWAPPINC  UNLOCKED  */ 

BC= 10;  DE= . INTSSTACKC  [ Ep]  ) ; 

HL= . S WAPS S TACK; 

CALL  I MGVBUF ] ; 

ENABLE; 

GOTO  [MONITOR]; 

END 

ELSE  TASKST IMER*  ( A=  1 ) ; 

END; 

END  TIMERSHDLR; 


TERMI NALSHDLR:  PROCEDURE; 

/**:S******!M:*********:**:*-,l;:K:S*:;:*********:f'***:***&:i:;S**#****/ 

/*  THIS  PROCEDURE  PROCESSES  THE  INTERRUPT  GENERATED  */ 
/*  FROM  ANY  KEY  DEPRESSION  AT  ANY  OF  THE  TERMINALS.  */ 

/*  IT  GETS  THE  TERMINAL  IDENTITY  AND  THE  KEYBOARD  */ 

/*  MATRIX  CODE  AND  THEN  CALLS  TERMI NAL3 I NPUTSCONTROL  */ 


/*  TO  PROCESS  THE  KEY.  */ 
/*  OUTPUT:  C - MATRIX  CODE  */ 
/*  F.  - TERMINAL  NUMBER  */ 
/*  CALLED  BY:  INTERRUFTSCONTROLLER  */ 


/********************:►•*********************************/ 
/*  READ  TERMINAL  IDENTITY  */ 

E= ( A= INC [ TERMIHALSLATCHl ) 03); 

/*  WRITE  TERMINAL  NUMBER  BACK  OUT  TO  CAUSE  */ 

/*  THE  APPROPRIATE  KEYBOARD  DATA  REGISTER  */ 

/*  TO  BE  SELECTED  FOR  READING.  */ 

OUT< [ TERM I N AL®  LATCH! ) = A: 

/*  READ  THE  KEYBOARD  MATRIX  CODE  */ 

C=  C A= IH<  [ MATR I XS LATCH] ) ) ; 

/*  PROCESS  KEY  */ 

CALL  [ TERMS INPUTSCTRL] ; 

END  TEKfll NALSHDLR; 


INTERRUFTSCONTROLLER:  /*  MAIN  ENTRY  INTO  INTMOD  */ 

/*  SAVE  CURRENT  VALUE  OF  STACK  POINTER  AND  */ 

/*  ALL  REGISTERS  IN  INTSSTACK  */ 

SAVHL* HL ; STACK* PSW; 

HL=2+SP;  P£  '1=  STACK; 

SP  = . INTSSTACK(  [ TOPI  ) ; 

STACK*  HL ; /*  PUSH  CURRENT  STACK  PTR  */ 

HL=SAVHL: 

STACK1 HL : /*  PUSH  ORIGINAL  CONTENTS  OF  HL  */ 

STACK1 DE ; STACK* BC;  STACK* PSW; 

DO  WHILE  [ INTSPENDINGI ; 
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H=(A=0);  L=  ( A=  I LEVEL! ) : 
DO  CASE  HL; 


/* 

0 

X/ 

CALL 

DUMMY3IIDLR; 

/X 

1 

X/ 

CALL 

CASSETTES HDLR; 

/* 

o 

X/ 

CALL 

DUMMYSHDLR; 

/X 

3 

X/ 

CALL 

DUMMYSnDLR; 

/X 

4 

X/ 

CALL 

DUMMY8HDLR: 

/X 

5 

X/ 

CALL 

DUMMYSHDLR; 

/X 

6 

X/ 

CALL 

PRINTERS HDLR; 

/X 

7 

X/ 

CALL 

DUMMY'S!  HDLR; 

/X 

8 

X/ 

CALL 

TIMERS HDLR; 

/X 

9 

X/ 

CALL 

DUMNYSHDLR; 

/X 

10 

X/ 

CALL 

TERM INALS HDLR; 

/X 

1 1 

X/ 

CALL 

DUMflYSHDLR; 

/X 

12 

X/ 

CALL 

DUMMYSHDLR; 

/X 

13 

X/ 

CALL 

DIJMMYSHDLR; 

/X 

14 

X/ 

CALL 

DUMMYSHDLR; 

/X 

15 

X/ 

CALL 

DUMMYSHDLR; 

/X 

END; 

16  */  CALL 
/*  CASE  */ 

DEBUG3HDLR; 

END:  /*  WHILE  */ 

/*  RESTORE  ORICINAL  VALUE  OF  STACK  POINTER  AND  */ 
/*  ALL  REGISTERS  FROM  INT3STACK  */ 

PS W= STACK;  BC=STACK;  DE= STACK;  KL= STACK; 

SAVHL=HL;  IIL=  STACK; 

SP=HL;  HL=SAVHL; 

ENABLE; 

RETURN; 

END  INTERRUPT3CONTROLLER  */ 


EOF 


/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/ 
/X  MONITOR  MODULE  */ 


/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/ 
/X  X/ 
/x  THE  MONITOR  MODULE  CONTAINS  THOSE  FUNCTIONS  OF  MTS  x f 
/x  WHICH  DEAL  WITH  PROCESSOR  MANAGEMENT.  SUCH  FUNC-  x/ 
/x  TIONS  INCLUDE  THE  INITIAL  PROGRAM  LO AD,  SYSTEM  x/ 
/x  RECOVERY,  SCHEDULING,  CPU  ALLOCATION,  AND  SWAPPING. */ 
/X  THE  MODULE  IS  DIVIDED  INTO  THREE  BASIC  SUBMODULES.  X/ 


/x 

/x 
/ x 
/x 
/x 
/x 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 

/X 


X/ 

(1)  UTILITY  PROCEDURES  */ 

THIS  SUBHODULE  CONTAINS  GENERAL  PURPOSE  *■/ 

UTILITY  PROCEDURES  WHICH  PERFORM  OPERATIONS  */ 
FREQUENTLY  REQUIRED  IN  THE  MONITOR,  INTERRUPT  */ 
AND  SERVICE  MODULES.  */ 

* INDEX  * PUT  */ 

* INDEX2  * GET  */ 

* INDEH4  * HOVBUF 

* INDF.XO  * MINISDISK  */ 

*/ 

(2)  TASK  MANAGEMENT  */ 

TOIS  SUBMODULE  CONTAINS  THE  SCHEDULING,  CPU  */ 
ALLOCATION,  AND  SWAPPING  PROCEDURES.  IT  .ALSO  */ 
INCORPORATES  THE  MECHANISM  FOR  RECORDING  THE  */ 
SYSTEM  STATE  BLOCK  WHEN  THE  SYSTEM  STATE 
CHANGES,  THUS  MAKING  RECOVERY  POSSIBLE.  */ 

CONTROL  PASSES  TO  THE  TASK  MANAGEMENT  */ 

SUBMODULE  AFTER  MTS  HAS  BEEN  INITIALIZED  BY  */ 
THE  I PL  SUBMODULE.  */ 

* MONITOR  * SWAP  */ 

* BUMPSTASK  * WRITF.3REC  */ 

* BOOTSTRAP  * RESUME3EXECUTI0N  */ 

*/ 

(3)  INITIAL  PROGRAM  LOAD  */ 


THIS  SUBMODULE  CONTAINS  .ALL  PROCEDURES  WHICH  */ 
DEAL  WITH  THE  LOAD  I NG  PROCESS  AFTER  THE  MTS  */ 
OBJECT  MODULE  HAS  BEEN  LOADED  UO'0  MEMORY  BY  */ 
THE  SYCOR  SYSTEM  LOADER.  THE  PHTOARY  FUNCTION  ■*/ 
OF  THE  I PL  SUBMODULE  IS  SYSTEM  INITIALIZATION 


OR  RECOVERY,  AS  REQUIRED.  IN  ORDER  TO  MINI-  */ 
MIZE  THE  MEMORY  REQUIREMENT  OF  THE  RESIDENT  */ 
MTS  CODE,  THIS  SUBMODULE  W.AS  WHITTEN  AS  A */ 
STANDALONE  PROGRAM  LOADED  INTO  THE  USER  SWAP  */ 
AREA.  ONCE  IPL  IS  COMPLETE  THE  PROGRAM  MAY  */ 
BE  OVERLAYED  BY  USER  PROGRAMS.  */ 

* ABORTS  I PL  * READSDIRECTORY  */ 

* SEARCHSD I RECTORY  * RECOVER  */ 

* INITIALIZE  * MTS3IPL  */ 

*/ 


/*  THE  MONITOR  MODULE  REQUIRES  ACCESS  TO  SEVERAL  */ 

/*  FILES  WHICH  RESIDE  ON  THE  MINI-DISK  IN  SYCOR  */ 

FORMAT.  THESE  FILES  AND  THEIR  FUNCTION  ARE:  */ 


/*  */ 
/*  (1)  . MTSSWP0 , . MTSSWP 1 , . MTSSWP2 , . MTSSWP3  */ 

/*  ASSOCIATED  WITH  EACH  OF  THE  FOUR  TERMINAL  */ 

/*  TASKS  IS  A FILE  USED  TO  STORE  A CORE  IMAGE  */ 

/*  OF  THE  TASK  WHEN  IT  IS  INACTIVE  OR  BLOCKED. 

THIS  SWAP  IMAGE  CONSISTS  OF  A SYSTEM  AREA 
/*  WHERE  THE  ENVIRONMENT  AND  VIRTUAL  DEVICE  */ 

/*  CONTROL  BLOCK  IS  STORED,  AND  A USER  AREA  */ 

/*  CONTAINING  THE  USER  PROGRAM’S  MEMORY  IMAGE.  */ 

/*  THE  MAXIMUM  SWAP  IMAGE  SIZE  IS  48K  BYTES.  */ 


/*  THEREFORE,  EACn  SWAP  FILE  SHOULD  NORMALLY  BE  */ 
/*  96  MINI-DISK  SECTORS  LONG.  IN  THE  EVENT  THAT  */ 
/■*  MINI-DISK  SPACE  IS  LIMITED  AND  THE  ENTIRE  48K  */ 
/*  IS  NOT  REQUIRED  FOR  USER  PROGRAMS,  MTS  WILL  */ 
/*  AUTOMAT  I C.ALLY  ADJUST  TO  ANY  FILE  SIZE  GREATER  */ 


/*  THAN  I6K  (32  SECTORS).  THE  FOLLOWING  SYCOR  */ 
/*  COMMAND  MAY  BE  USED  TO  CREATE  A SWAP  FILE-’  */ 
/*  CREATE  < FILENAME)  N=96  */ 
/*  THE  SYCOR  SYSTEM  DOES  NOT  ALLOW  DYNAMIC  */ 


/*  CHANGES  IN  FILE  SIZE  OR  ATTRIBUTES:  THUS,  IN 
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/*  ORDER  TO  CHANCE  THE  FILE  SIZE,  THE  FILE  MUST  */ 

/*  FIRST  BE  DELETED  (DELETE  < F I LENAME> ) AND  THEN  */ 

/*  RECREATED  WITH  THE  DESIRED  SIZE.  IF  SWAP  */ 

/*  FILES  SMALLER  THAN  48K  ARE  DESIRED,  THE  VALUE  */ 

OF  N IN  THE  CREATE  COMMAND  STRING  SHOULD  BE  */" 
/*  TWO  TIMES  THE  REQUIRED  PROCRAM  SPACE  IN  */ 

/*  KILOBYTES.  */ 

/*  THE  FOUR  SWAP  FILES  ARE  ONLY  REQUIRED  WHEN  */ 

/*  MTS  IS  ACTUALLY  RUNNING.  OR  BETWEEN  RUNS  IF  */ 

/*  RECOVERY  WILL  BE  REQUESTED.  */ 

*■/ 

(2)  . MTSCNFG  */' 

/*  THE  VIRTUAL  FLOPPY  DISK  CONF I CURAT I ON  FILE  */ 

/*  PROVIDES  THF.  MAPPINC  BETWEEN  T1IE  VIRTUAL  DISK  */ 

NUMBER  (0-31)  .AND  THE  NAME  OF  A SYCOR  FILE  */ 
/*  WHICH  CONTAINS  A FLOPPY  DISK  1 MACE . THE  COR-  */ 

/*  F I CURAT I ON  FILE  ALSO  CONTAINS  THE  PROTECTION  */ 

/*  ATTRIBUTES  OF  THE  VIRTUAL  DISKS.  WHERE  A 

/•*  PHYSICAL  FLOPPY  DISK  ILAS  A FIXED  CAPACITY  OF  */• 

/-*  256K  BYTES.  AN  MTS  DISK  IMAGE  MAY  HAVE  ANY  */ 

/*  CONVENIENT  SIZE.  THE  SYSTEM  ASSUMES  THAT  THE  */ 

/*  DISK  IMAGE  IS  STORED  SEQUENTIALLY  ON  THE  */ 

/*  MINI-DISK  STARTINC  WITH  TRACK  0 SECTOR  I AND  */ 

/*  PROCEEDING  THROUGH  26  SECTORS  OF  TRACK  0 TO  */ 

S*  TRACK  1 SECTOR  O,  ETC.  SPECIFYING  A VIRTUAL  */* 

/*  DISK  FILE  SMALLER  THAN  256 K BYTES  MEANS  THAT  */ 

/*  FEWER  THAN  77  TRACKS  WILL  BE  ADDRESSABLE,  */ 

/*  WHILE  A SIZE  GREATER  THAN  256K  BYTES  WILL  */ 

/*  MAKE  MORE  THAN  77  TRACKS  ADDRESSABLE,  UP  TO  */ 

/*  A MAXIMUM  OF  256  TRACKS.  IN  EITHER  CASE  MTS 

/*  AUTOMATICALLY  ADJUSTS  THE  UPPER  BOUND  BASED  */ 

ON  'nrF.  FILE  SPACE  AVAILABLE. 

/*  THE  CONF I ORATION  FILE  CONTAINS  32  THIRTEEN  */ 

/%  BYTE  RECORDS  IN  TOE  FOLLOWING  FORMAT:  */ 

/*  */ 

/*  I FILENAME  I KEY  I P I 

/■*.  

/%  0 7 8 11  12  */ 

WHERE  ’FILENAME’  IS  THE  0-8  BYTE  NAME  OF  THE 
/*  VIRTUAL  DISK  FILE  AS  IT  APPEARS  IN  THE  SYCOR  */ 

/*  DIRECTORY;  ’KEY’  IS  A 0-4  BYTE  PROTECTION  */ 

/*  KEY;  AND  ’P’  IS  TOE  PROTECTION  ATTRIBUTE  OF  *✓ 

/*  THE  DISK,  I.E.  ’P’  FOR  READ/ WRITE  PROTECTION,  */ 

/*  ’R’  FOR  WRITE  PROTECTION  ONLY,  AND  BLANK  FOR  */ 

/*  NO  PROTECTION.  */ 

/*  THE  CONFIGURATION  FILE  WILL  BE  UPDATED  BY  THE  */ 

/*  MTS  SYSTEM  COMMANDS  PROTECT,  UNPROTECT,  AND  */ 

/*  RESTRICT.  ALTERNATIVELY,  IT  MAY  BE  MODIFIED  */ 

/*  USING  SYCOR’ S DATA  ENTRY  FREE  FORM  NODE.  IN  */ 

/*  THE  EVENT  THAT  .MTSCNFG  IS  ERRONEOUSLY  */ 

/*  DELETED,  THE  FILE  MAY  BE  RECREATED  BY  USING  */ 

/*  THE  SYCOR  COMMAND  */ 

/*  RUN  RESTORE  2=/CSST  */ 

/*  WITH  THE  CASSETTE  LABELED  ".MTSCNFG  DUMP"  */ 

/*  MOUNTED  ON  THE  CASSETTE  DRIVE.  */ 

/*  */ 

/*  (3)  . MTSRCVR  */ 

/*  TOE  RECOVERY  FILE  CONTAINS  A COPY  OF  THE  */ 

/*  SYSTEM  STATE  BLOCK  AS  OF  THE  LAST  SWAP.  THE  */ 

/*  FILE  IS  ONLY  REQUIRED  WHEN  MTS  IS  ACTUALLY  */ 

/*  RUNNING,  OR  BETWEEN  RUNS  IF  RECOVERY  WILL  BE  *✓ 

/*  REQUESTED.  THE  FOLLOWING  SYCOR  COMMAND  IS  */ 

/*  USED  TO  CREATE  THE  FILE:  */ 

/*  CREATE  . MTSRCVR  N= I */ 

/*  */ 
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/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/ 
✓ **************:****  TASK  MANAGEMENT  XXXXXXXXXXXXXXXXXXXS 
/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/ 


SXXXXXXXXXXXXX  INTERMODULE  LINKACE  MACROS  XXXXXXXXXXXXX/ 

[ INT  TB  M2B3  [TB:=1000H3  [M2B:=06Q0H3 
[MACRO  MCP  ’ 1A00H’ I 
[ MACRO  MTS  ’ 1FOOH' ] 

[ MACRO  INDEX  ’[HEX  M2B  + 3HI  ’ 1 
[MACRO  INDEX2  ’[HEX  M2B  + ODH] ' ] 

[ MACRO  INDEXB  ’ [ HEX  M2B  + 24H3 ’ I 
[ MACRO  CET  ’ [ HEX  M2B  + 38HJ ’ I 
[MACRO  MINI3DISIC  ’[HEX  M2B  + 54H3  ’ 3 
[ MACRO  MTSSMSG  ’ [ HEX  TB  + 837H3 ’ 3 
[MACRO  READ3TERMINAL  ’ [ HEX  TB  + 8DCH3  ’ 3 
[ MACRO  GETSTERNSSTATUS  ’ [ HEX  TB  + 2F9H3 ’ 3 

/xxxxxxxxxxxxxxx  GENERAL  PURPOSE  MACROS  xxxxxxxxxxxxxxx/ 

[ INT  MEMS8ASE  TOP  TIMESLICE3 

[ MEM3BASE:  = 400011]  [TIMESLICE:  =43  [TOP:  =203 

[MACRO  SSB3BASE  ’ TASK*  3 

[MACRO  SWAPS BASE  ’VDCCDRIVE’3 

[ MACRO  READ  ’ 1 ’ 3 

[MACRO  WRITE  ’2’ 3 

[ MACRO  BUMP  ’ -2 ’ 3 

[MACRO  DISKGERROR  ’<A::0)  ! ZERO' 3 

[ MACRO  HARDWARES ERROR  ’ 8 ’ 3 
[MACRO  INPUTS WAITING  ’OFFH’3 
[ MACRO  IN  ’ [ READ! ’ 3 
[ MACRO  OUT  ’ [WRITE!  ’ 3 

/*********#>:*:!!***  MODULE  DECLARAT IONS  **#**************/ 

DECLARE  (MONITOR,  BOOTSTRAP , RESUME3EXECUT ION)  LABEL; 
DECLARE  DIR  DATA  (0)  ; 

DECLARE  SAVHL  DATA  (0,0); 

DECLARE  I DATA  ( O)  ; 

DECLARE  TN  DATA  (0); 

/xxxxxxxxxxxxxxxxxxxxx  PROCEDURES  xxxxxxxxxxxxxxxxxxxxx/ 
BUMPSTASK:  PROCEDURE; 

/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ 

/%  THIS  PROCEDURE  DELETES  A TASK  FROM  THE  SYSTEM  WHEN  */ 
/*  AN  IRRECOVERABLE  MINI-DISK  ERROR  OCCURS.  */ 

/x  CALLED  BY:  SWAP,  BOOTSTRAP  */ 

/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXS 

C=  [ BUMP 3 ; CALL  IMTS3; 

E=[  HARDWARESERROR] ; CALL  [ MTSSMSG 3 ; 

END  BUMPSTASK; 

SWAP:  PROCEDURE; 

/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/ 
/*  THIS  PROCEDURE  SWAPS  A TERMINAL  TASK  BETWEEN  MEMORY*/ 


/*  AND  THE  APPROPRIATE  MINI-DISK  SWAP  FILE.  THE  DIR-  */ 
/*  ECTION  OF  THE  SWAP,  I.E.  IN  OR  OUT,  IS  DETERMINED  */ 
/*  BY  THE  VALUE  OF  THE  VARIABLE  DIR.  THE  */ 
/*  PROCEDURE  ALSO  MODIFIES  TCTSSTATUS  TO  REFLECT  THE  */ 
/*  CURRENT  LOCATION  OF  THE  SWAP  IMAGE.  */ 
/*  INPUT:  DIR  - DIRECTION  OF  SWAP  */ 
/*  1 = IN  */ 
/*  2 = OUT  */ 
/*  CALLED  BY:  MONITOR  */ 


/ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX / 
/*  SET  I TO  SWAP  IMAGE  SIZE  */ 

DE= . TCTSS IZE;  A=TASK;  CALL  [INDEX]; 

I=(A=M(HL)>; 

/*  MODIFY  TCTSSTATUS  X/ 
nL= . TCT3STATUS+BC ; 
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M(HL)  = (A=M(HL>  \\  OCOH) ; 

sr-  SET  UP  REGISTERS  FOR  DATA  TRANSFER  */ 

DE= . TCTSBOE;  A= TASK;  CALI.  [ INDEX2]  : CALL  [ GET] j 
DE= . [ SWAP3BASE] ; A= I ; 

DO  WHILE  (A: : 0)  IZF.RO; 

L=(A=DIR>;  CALL  tMINISDISK]; 

IF  I DISKSERROIU  THEN 

DO;  BUMP  TASK  OFF  SYSTEM  */ 

CALL  BUMPSTASK; 

IF  ( A=  DIR;  A:-.  I nil)  ZERO  GOTO  MONITOR; 
RETURN; 

END; 

BC=BC+1;  DE=( HL=200H+DE) ; 

I = (A=  1-1)  ; 

END;  /*  WHILE  */ 

END  SWAP; 

WRITESREC:  PROCEDURE; 


/X  THIS  PROCEDURE  COPIES  THE  CONTENTS  OF  THE  SYSTEM  */ 

/*  STATE  BLOCK  TO  THE  RECOVERY  FILE.  THE  VARIABLE  */ 

/-*  REC3FILE  MUST  DE  SET  TO  THE  FILE’S  SECTOR  ADDRESS 
/*  BEFORE  CALLING  WRITESREC. 

/■*  CALLED  BY:  BOOTSTRAP,  RESUMESEXECUTION  */ 


BC=  ( HL=  RECSF  ILE)  , DE=  . ISSBSBASEl  ; 
L=[  WRITE];  CALL  tMINISDISK]; 

IF  t D ISKSERROR]  THEN  HALT; 

END  WRITESREC; 

MONITOR: 


/*  THIS  ROUTINE  IS  THE  TASK  MANAGER  OR  SCHEDULER  */ 

/*  WRICI1  CONTROLS  THE  ALLOCATION  OF  TIIE  CPU  TO  COM-  */ 
/*  PETING  TERMINAL  TASKS.  IT  PERFORMS  THIS  FUNCTION  *■/ 
/*  BY  SEQUENTIALLY  SCANNING  THE  TGTSSTATUS  BYTE  *■/ 

/*  ASSOCIATED  WITH  EACH  TERMINAL  LOOKING  FOR  A TASK  */ 
REQUIRING  THE  GPU.  THE  EFFECT  PRODUCED  IS  THAT 
/*  OF  A ROUND-ROBIN  SCHEDULING  ALGORITHM.  WRILE  THE  */ 

/*  MONITOR  IS  LOOPING,  IT  INITIATES  SWAPPING  AND  */ 

/*  PRINTING  OF  SPOOLER  FILES  AS  REQUIRED.  */ 

/*  CALLED  BY:  flTSSIPL,  MTS  (SVCMOD)  */ 


SP= . SYSSSTACKt  t TOP] ) ; /*  SET  STACK  POINTER 

✓ * LOCK  OUT  SWAPPING 
LOCX=  ( A=  LOCK  \ 0 1 H)  : 

/%  INITIALIZE  TEMP  TASK  COUNTER  */ 

TN=  ( A=  TASK)  ; 

LOOP:  /*  SEARCH  FOR  READY  TASK  */ 

TN= ( A=TN+ 1 , S03H) ; /»  INCREMENT  TASK  NUMBER  */ 
/*  TEST  FOR  INACTIVE  TASK  */ 

DE= . TCTSSTATUS ; CALL  [INDEX];  A=M(HL); 

IF  ( A : : 0 ) ZERO  GOTO  LOOP; 

/■*  TEST  BIT  0 - BOOTSTRAP  LOAD 
IF  ( A=>  A)  CY  THEN 
DO; 

DE= . TCTSSTATUS ; A=TASK;  CALL  [INDEX]; 

IF  ( A=<  MC  HL)  ) CY 

(B=(A=TN);  A=TASK-B)  ’ZERO  THEN 

DO;  D I R=  ( A=  [ OUT] ) ; CALL  SWAP;  END; 
TASK=  ( A=  TN ) ; 

GOTO  BOOTSTRAP; 

END; 

TEST  BIT  1 - MCP 
IF  ( A=  > A)  CY  THEN 
DO; 

A=  TASK : STACK=PSW;  /*  SAVE  OLD  TASK  NR  */ 
TASK=  ( A=TN)  ; CALL  C MCP 3 ; 

DE=  . TCTSSTATUS ; A=  TN ; CALL  [INDEX]; 

M(  IIL)  =(  A=M(  HL)  OFDH)  : 

RESET  3IT  1 */ 

PS V= STACK:  TASK=A; 


/*  RESTORE  OLD  TASK  NR  */ 

TN=( A=TN-1 ,303H) ; GOTO  LOOP: 

/*  CONTINUE  WITH  TASK  AFTER  */ 
/*  SYSTEM  CALL  FROCESSED  */ 

END; 

/*  SKIP  BIT  2 - RESERVED  FOR  CASSETTE  */ 

A=>  A; 

/*  SKIP  BIT  3 - RESERVED  FOR  ASYNC  */ 


A=>  A; 

/*  SKIT  BIT  4 - BLOCKED  FOR  PRINTER  I/O  */ 

A=>  A; 

/*  TEST  BIT  5 - BLOCKED  FOR  TERMINAL  I/O  */ 

IF  ( A=  > A)  CY  THEN 
DO; 

A=TN;  CALL  [ CETSTERPISSTATUS I ; 

IF  ( A: : I INPUTSWAITINGI ) ZERO  THEN 
DO;  /*  NO  LONGER  BLOCKED  */ 

DE= . TCT8STATUS ; A=TASK;  CALL  C INDEX!  ; 
IF  ( A=<  MC  HL) ) CY 

8 <B=(A=TN>;  A=TASK-B)  !ZERO  THEN 

DO;  DIR=  ( A=  I OUT!  ) ; CALL  SWAP;  END; 
TASK=( A=TN) ; 

DIR=CA=C INI ) ; CALL  SWAP; 

CALL  C READSTERMINALI  ; 

SWAPSSTACKI  l ) = A ; 

/*  RETURN  CHAR  REQUESTED  */ 

DE=  . TCTSSTATUS ; A=TASK;  CALL  [INDEX!; 
M(HL)  = < A=M(HL)  ODFH)  ; 

/*  RESET  BIT  5 */ 

GOTO  RESUMES  EXECUTION ; 

END 

ELSE  GOTO  LOOP; 

END; 

/*  TEST  BIT  6 - RESUME  EXECUTION  - FM  DISK  */ 
IF  <A=>A>  CY  THEN 
DO; 

DE= .TCTSSTATUS;  A=TASK;  CALL  [INDEX!; 

IF  ( \-<  M(  HL)  ) CY  THEN 

DO;  D I R=  < A= [ OUT! ) : CALL  SWAP;  END; 
TASK=(  A=TN)  ; 

DIR=( A=[ IN!) ; CALL  SWAP; 

GOTO  RESUMESEXECUTION; 

END; 

/*  BIT  T SET  - RESUME  EXECUTION  - IN  MEMORY  */ 
GOTO  RESUMESEXECUTION; 

/*  END  MONITOR  */ 


BOOTSTRAP : 

/******************************************************/ 
/*  THIS  ROUTINE  EXAMINES  THE  DISK  PLAP  FOR  THE  CURRENT  */ 
/*  TASK;  DETERMINES  THE  VIRTUAL  DISK  ATTACHED  TO  DRIVE*/ 
/*  A;  LOADS  THE  FIRST  512  BYTES  FROM  THE  DISK  INTO  */ 
/*  MEMORY  STARTING  AT  THE  BASE  OF  THE  USER  SWAP  AREA;  */ 
/*  AND  THEN  TRANSFERS  CONTROL  TO  THE  CODE  JUST  LOADED.*/ 
/******************************************************/ 
/*  DETERMINE  DISK  NR  ATTACHED  TO  DRIVE  A */ 

DE= . TCT3DM;  A=TASK;  CALL  [ INDEX8! ; 

A- M(  HL)  1FH; 

/*  DETERMINE  BOE  FOR  DISK  */ 

DE= . DMT3BOE;  CALL  [ INDEX21 ; CALL  [GET!; 

/*  READ  FIRST  SECTOR  ON  VIRTUAL  DISK  */ 

DE=  I PIEP13BASE!  ; L=  [ READ!  ; CALL  [MINISDISKI; 

IF  [ D ISK$ ERROR!  THEN 

DO;  /*  BUPIP  TASK  OFF  SYSTEM  */ 

CALL  BUPIPSTASK; 

CALL  WRITE9REC; 

GOTO  PIONITOR; 

END; 

/*  UPDATE  SYSTEM  STATUS  */ 

DE=  . TCTSSTATUS ; A=  TASK;  CALL  [INDEX!; 

A=M(HL)  N 60H;  /*  SET  BIT  7 */ 

H(  HL)  = C A=  A OFEn)  ; /*  RESET  BIT  0 */ 
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CALL  WRITESREC; 

TVSK9TIMER=(  A’tTIMESLICEI > ; /*  RESET  TASKSTIMF.R  */ 

LOCK=  ( A=  LOCK  OFEII)  ; /*  UNLOCK  SWAPPING  */ 

SP=OFEFEH; 

COTO  [ MEMSBASEI ; 

/*  END  BOOTSTRAP 


RESUMESEXECUTIOH: 

✓'*******:s:i:*************W****:s*:R**w****W*«****!**!f!*****:*:*'' 
/*  this  ROUTINE  TRANSFERS  CONTROL  BACK  TO  A USER  TASK  */ 
/*  WniCH  HAS  BEEN  SWAPPED  INTO  MEMORY.  */ 

/'***XX**X**X#X****X**X##***#X**XXX*:I:**XX*X*************/ 

CALL  WRITESREC; 

/*  UPDATE  SYSTEM  STATUS  */ 

TASK3TI MER= ( A=  I TIMESLICE1 ) ; /*  RESET  TASKSTIMER  */ 

/*  RESTORE  ORIGINAL  VALUE  OF  STACK  POINTER  *s 
/*  AND  ALL  REGISTERS  FROM  SWAP8STACK  */ 

SP= .SWAPSSTACK; 

PSW=  STACK;  BC=STACK;  DE=STACK;  HL=  STACK; 

SAVHL=HL;  HL= STACK; 

SP=  IIL;  IIL=SAVHL;  /*  RESTORE  USER  SP 
STACK=rSW; 

LOCK" ( A=  LOCK  OFEH)  ; /*  UNLOCK  SWAPPING  */ 

PSW=STACK; 

RETURN;  /*  RETURNS  TO  INTERRUPT  POINT  *✓ 

IN  USER  SWAP  I MAGE 
/X  END  RESUMESEXECUTION  */ 


EOF 

/**#****«*"  ■XXX*»XXXXXX*XXXXXXXXXXXXX*XXX^XX*XXXXX»XXXX»^ 
/XXXXXXXXXxXXXXXX*  UTILITY'  PROCEDURES  XXXXXXXXXXXXXXXX*/ 
/*:S**:K*#:R****:S*»**X:S*****«***»**#************:f:«**=l:  X****/ 


INDEX:  PROCEDURE; 

/****««**»  Si********:***:!:  **X****:S*************************/ 


sx  GIVEN  THE  BASE  ADDRESS  OF  A BYTE  VECTOR  AND  AN  *■/ 
/■*  INDEX  VALUE.  THIS  PROCEDURE  CALCULATES  THE  ADDRESS  */ 
/x  OF  THE  INDEXED  ENTRY.  */ 
/X  INPUT:  A - INDEX  VALUE  (USUALLY  TASK) 

/*  DE  - BASE  ADDRESS  OF  VECTOR  */ 
/■*  OUTPUT:  BC  - INDEX  VALUE  */ 
/*  DE  - SAME  AS  INPUT 

/*  HL  - CALCULATED  ADDRESS  OF  INDEXED  ENTRY  X/ 
/x  CALLED  BY:  SWAP,  MONITOR.  VALSDISK,  CLEARSFLAG,  */ 
/*  ATTACH.  LOGIN,  QUIT,  SIZE,  TERMSBLOCK.  */ 
/*  SELECTSDRIVE  */ 


/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ 
B=0:  C= A; 

HL=BC+DE; 

END  INDEX; 


I NDEX2 : PROCEDURE ; 

/#***:fc*****:S****:|:***»*******:f!**  ******»***:**************✓ 

/X  GIVEN  THE  BASE  ADDRESS  OF  AN  ADDRESS  VECTOR  AND  AN  */ 
/*  INDEX  VALUE,  THIS  PROCEDURE  CALCULATES  THE  ADDRESS  */ 


/X  OF  THE  LOW  ORDER  BYTE  OF  THE  INDEXED  ENTRY.  */ 
/*  INPUT:  A - INDEX  VALUE  (USUALLY  TASK)  */ 
/*  DF.  - BASE  ADDRESS  OF  VECTOR  */ 
/-*  OUTPUT:  BC  - CALCULATED  OFFSET  * 2 * INDEX  VALUE  */ 
/*  DE  - SAME  AS  INPUT  */ 
/*  HL  - CACULATED  ADDRESS  OF  INDEXED  ENTRY  */ 
/»  CALLED  BY:  SWAP,  BOOTSTRAP,  SIZE,  SELECTSDRIVE  */ 


/X*%if-X*XX*XXX****XXX.X%XXXXX  XXXXXX***%XXXXXXXXXXX-XXXXXXX./ 

B=0;  C=  ( A=<  < A)  ; 

HL=  BC  + DE; 

END  INDEX2; 


INDEX4 : PROCEDURE: 

/'***»**sc***r**»»:**vc:/t***»t**»:*****»^S!*W^*****************^ 

/x  INPUT:  A - INDEX  VALUE  *s 


166 


✓*  DE  - BASE  ADDRESS  OF  VECTOR  */ 

/*  OUTPUT:  BC  - CALCULATED  OFFSET  = 4 * INDEX  VALUE  */ 
/*  DE  - SAME  AS  INPUT  */ 

HL  - CALCULATED  ADDRESS  OF  INDEXED  ENTRY  */ 
/*  CALLED  BY:  VALSKEY  */ 


yxXXXXXXXXXXXXXX**XXXXXXXXXXX*XXXXXXXXXXXXXXXXXXXXXXXXXy 
B=0;  C=<  A=<<  ( A=<<  A)  ) ; 

IIL=  EC+DE : 

END  INDEX4 ; 

INDEXB:  PROCEDURE; 

xxxSzXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXy 


/*  INPUT:  A - INDEX  VALUE  */ 
y*  DE  - DASE  ADRESS  OF  VECTOR  */ 
/*  OUTPUT:  BC  - CALCULATED  OFFSET  = 8 * INDEX  VALUE  */ 
/*  DE  - SAME  AS  INPUT  */ 
/X  HL  - CALCULATED  ADDRESS  OF  INDEXED  ENTRY  */ 
/*  CALLED  BY:  BOOTSTRAP,  VALSDRIVE,  CLEARSDM,  ATTACH,  */ 
/*  SELECTSDRIVE  */ 


yXXXXXXStXXXXXXXStXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXxy 
D*  O ; C=(  A*<<  ( A=<<  ( A3<<  A)  ) ) ; 

HL=  BC+DE; 

END  INDEXB; 

PUT:  PROCEDURE; 


/*  STORE  A TVO  BYTE  ADDRESS  IN  A SPECIFIED  VECTOR.  */ 
/*  INPUT:  DE  - ADDRESS  TO  BE  STORED  */ 
/*  HL  - BASE  ADDRESS  OF  VECTOR  */ 
yx  OUTPUT:  BC  - UNCHANGED  */ 
yx  DE  - SAME  AS  INPUT  */ 
/St  HL  - BASE  ADDRESS  + 1 */ 
/*  CALLED  BY:  RECOVER,  INITIALIZE  */ 


yxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxstxxxxxxxxxxxxxxxxxxxx/ 
M(  HL ) = E ; HL=HL+ 1 ; M(  HL)  = D: 

END  PUT: 

GET:  PROCEDURE; 

/is*****  JR*****:?:  is*/ 

/»  FETCH  A TWO  BYTE  ADDRESS  FROM  A SPECIFIED  VECTOR.  */ 


/*  INPUT:  IIL  - BASE  ADDRESS  OF  VECTOR  */ 
yx  OUTPUT:  BC  - ADDRESS  FETCHED  */ 
/%  DE  - ADDRESS  FETCHED  */ 
/*  HL  - BASE  ADDRESS  + I */ 
/*  CALLED  BY:  SWAP,  BOOTSTRAP,  SIZE,  SELECTSDRIVE  */ 


y^XtKXXXXXXXXXXXXXXXXXXtKXXXXXXXXXXX^XXXXXXXXXXXttt^tXXXXXXxy 

E=M(HL);  HL=HL+1;  D=M(HL);  BC  = DE; 

END  GET: 

MOVBUF : PROCEDURE; 

yXX*XXXXX**'XXXXXXXXXXXXXXxXXXXXXXXXXXX»XX*XXX*XXXXXXXXX/ 
/*  THIS  IS  A GENERAL  PURPOSE  UTILITY  PROCEDURE  WHICH  */ 


/*  MOVES  A SPECIFIED  NUMBER  OF  BYTES  FROM  A SOURCE  */ 
/*  BUFFER  TO  A DESTINATION  BUFFER.  */ 
y*  INPUT:  BC  - NUMBER  OF  BYTES  TO  BE  MOVED  *y 
y * DE  - BASE  ADDRESS  OF  SOURCE  BUFFER  *y 
y * HL  - BASE  ADDRESS  OF  DESTINATION  BUFFER  */ 
/*  CALLED  BY:  MTS8IPL,  ABORTSIPL,  SEARCHSD I RECTORY,  */ 
/*  LOGIN,  READSFLOPPY,  VRITESFLOPPY  */ 


/ ******  .-..I:***##******#********#*************************/ 

REPEAT; 

M<  HL)  »(  A=M(  DE)  ) ; 

HL=  HL+ 1 ; DE=DE+ 1 ; 

UNTIL  ( BC=  BC- 1 ; A=0;  A::C)  ZERO  (A::B)  ZERO: 

END  MOVBUF; 

MINI3DJSK:  PROCEDURE; 

/*«**********************************»*M:******»:***:t:»***// 

/*  THIS  PROCEDURE  TRANSFERS  A SPECIFIED  512  BYTE  */ 

y*  BUFFER  BETWEEN  MEMORY  AND  THE  MINI-DISK.  THE  DIR-  */ 
/*  ECTION  OF  TOE  TRANSFER  IS  INDICATED  BY  TOE  OP  CODE.*/ 
/*  ERROR  PROCESSING  IS  LIMITED  TO  CHECKING  THE  STATUS  */ 


167 


/*  RETURNED  BY  THE  MINI-DISK  CONTROLLER  FOR  ’NORMAL  */ 
/*  COMPLETION.’  WHEN  ANY  OTHER  STATUS  IS  RETURNED  THE  */ 
/*■  ROUTINE  DISPLAYS  TIIE  MESSACE  ’HARDWARE  ERROR’  ON  */ 
/*  THE  TERMINAL  CURRENTLY  ALLOCATED  THE  CPU  AND  */ 
/*  ABORTS  TIIF,  OPERATION.  */ 
/*  INPUT:  BC  - MINI-DISK  SECTOR  NUMBER  */ 
/*  DE  - DMA  BUFFER  BASE  ADDRESS  */ 
/*  L - OPERATION  CODE:  */ 
/*  1 = READ  */ 
/*  2 - WRITE  */ 
/*  3 = WRITE/ VERIFY  */ 
/w  OUTPUT:  A - RETURNS  O0II  IF  COMPLETION  NORMAL,  */ 
/*  OTHERWISE  RETURNS  FFH  */ 
/*  EC  - SAME  AS  INPUT  */ 
/*  DE  - SAME  AS  INPUT  */ 
/*  CALLED  BY:  RF.ADSD  I RECTORY,  RECOVER,  INITIALIZE,  */ 
/*  WRITESREC, SWAP , BOOTSTRAP , READSBUF , */ 
/%  WRITESBUF  */ 


[MACRO  ABNORMALSCOMPLETION  ’OFFH'I 
[MACRO  HARDWARES ERROR  ’8’ I 
[MACRO  MTSSPiSG  ’1837H’] 

/*  SET  DCB  CHECKSUM  IN  LOCN  4CH  */ 

Pl(4Cn)  = (A=0\B,NC,ND,\E.\L)  ; 

/*  SET  SECTOR  NUMBER  IN  DISK  CONTROL  BLOCK  */ 

M(  43H)  = ( A=B)  : M(  44H)  = ( A=C)  ; 

/*  SET  DMA  BUFFEH  ADDRESS  IN  DISK  CONTROL  BLOCK  */ 

M( 43H) -C A=D)  ; M( 42H)  = ( A=  E) ; 

/*  INITIATE  OPEIUTION  */ 

M( 40H) = ( A=L) ; 

/*  WAIT  UNTIL  OPERATION  COMPLETE  */ 

REPEAT: 

A- Ml  4 1H)  : 

UNTIL  ( A : : 0 ) TZERO: 

/*  TEST  A FOR  COMPLETION  STATUS  */ 

IF  (M(41H)=(  A=A-1> ) ZERO  RETURN;  /*  NORMAL  COMPLETION  */ 
M(41H)  = ( A=0)  ; 

E= [ HARD WARES ERROR]  : 

CALL  [ MTSSMSG] ; 

A=[ ABNORMALSCOMPLETION]  ; 

END  MIN ISDISK: 


EOF 

/*****:**.'):***:£**:£*  INITIAL  PROGRAM  LOAD  ****************/ 

/*******V:**»:*^******w:«*il:>:*****a:**:S******S:*^**:C*******S:«/ 


/*************  INTERMODULE  LINKAGE  MACROS  *****k**c****/ 
[ INT  MB  M2B  SB  TB] 

[ MB: =0300HI  [M2B:=0600H]  [SB:=1F0OH]  [TB:=1OO0H] 

[MACRO  MONITOR  ’[HEX  MB  + 8FH]  ’ J 
[MACRO  M0V3UF  ’[HEX  M2B  + 41111’] 

[MACRO  PUT  ’[HEX  M2B  + 31H]’] 

[MACRO  MIN ISDISK  ’[HEX  M2B  + 54H] ’ ] 

[MACRO  MTS  ’(HEX  SB  + 0]’] 

[ MACRO  MTSSMSG  ’ [ HEX  TB  + 837H] ’ ] 

[MACRO  CLEARSSTATUSSL I NE  ’[HEX  TB  + 827H] ’ ] 

[MACRO  TERM  I NALSSTATUS  ’[REX  TB  + 8D2U]  ’ ] 

[MACRO  READSTERMINAL  ’[HEX  TB  + 8DCU1 ’ ] 

[MACRO  WRITES TERM INAL  ’[HEX  TB  + 93CH] ’ I 
[ MACRO  RECSFILE  ’3E91H’] 

[MACRO  TCT3E0E  ’3EC5H’ ] 

[ MACRO  CNFCSF ILE  ’ 3E93H’ ] 

[MACRO  DMTSFLAG  ’ 3ECDH’ ] 

[MACRO  DMTSBOF.  ’ 3EF.DH’  ] 

[MACRO  DMTSEOE  ’ 3F2DH’ ] 

[MACRO  D MTS KEY  ’ 3F6DH’ ] 

[MACRO  SA’SSSTACK  ’ 3C7  AH’  ] 
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X***************  CENERAL  PURPOSE  MACROS  ***************/ 

[ I NT  ME  MS  BASE  DIRSBASE  SSBSBASE  TOPI 
[ MEM9BASE:  =500011]  I SSBSBASE:  = 3E901II  [T0P:=20J 

[ D I R3BASE : = MEM3BASE  + 200ni 
[ MACRO  READ  ’ 1 ’ I 

[MACRO  DISKSERROIl  ’(A::0)  ! ZERO'  I 

[ MACRO  D I S ABLEST I MER  ' OUT( 2 ) = ( A= 1 ) ’ I 
[MACRO  CLEAR9CSSTS I NT  ‘ OUT( OSH)  = ( A= 10H)  ’ 1 
[ MACRO  CLF.  ARSPRNTS  I NT  ’ A=  I IK  BAR)  ’ ] 

[ MACRO  RESETSTIMER  ’ OUT( 2)  = ( A=0) ’ 1 

/*:*:(:**:t::*:fc**:|:***:!:*  MODULE  DECLARATIONS  IK********:!:********/ 


DECLARE  I BYTE; 

DECLARE  MAX(  2 ) BYTE; 

/*  ADDRESS  OF  LAST  ENTRY  + 1 IN  DIRECTORY  IMAGE  */ 
DECLARE  RECSNAMEC  9)  BYTE  INITIAL  ( ’ . MTSRCVRS ’ ) ; 

^ ***-.,<*:*  a:****  ********  PROCEDURES  ***********************/ 


ABORTSIPL:  PROCEDURE( MSG) ; 

/******:S:************:K****:|::(:::;**:|:::::fc:is:!::!:*****:!c:!s:i::S***:(::l::i:*.***/' 

/*  MIEN EVER  A CONDITION  OCCURS  DURINC  THE  IPL  PROCESS  */ 
/*  WHICH  PREVENTS  NORMAL  COMPLETION  OF  THE  IPL  THIS  */ 


/*  PROCEDURE  IS  CALLED  TO  TERMINATE  EXECUTION  AND  */ 
/*  DISPLAY  AN  ERROR  MESSACE  AT  TERMINAL  0.  */ 
/*  INPUT:  MSG  - BASE  -ADDRESS  OF  ERROR  MESSAGE  */ 
/*  TERMINATED  BY  ’ 3 ' */ 
/*  CALLED  BY:  READ3D I RECTORY,  INITIALIZE,  RECOVER,  */ 


/ * * ** * :;c*  * :::  * * ::: :::  * ^ * * * * * * -V:  * * * **  * / 

DECLARE  ABORTSMSG  DATA  ( ’ IPL  ABORTED  - ’); 

/*  DISPLAY  ' IPL  ABORTED'  AT  TERMINAL  0 */ 

BC=  14  ; DE=  . ABORTS  MSG;  IIL=0700H; 

CALL  C MOVBUFI ; 

IIL=  MSG;  A=’S'; 

DO  C=0  BY  C=C+1  WHILE  ( A:  : M(  HL) ) 'ZERO; 

HL=  HL+ 1 ; /*  COUNT  CRARS  IN  MSG  */ 

END: 

B=0;  DE=  ( HL=  MSG)  ; 1IL-070EH; 

CALL  [MOVBUFI;  /*  DISPLAY  MSG  AT  TERMINAL  0 */ 

HALT: 

END  ABORTSIPL; 


READSD I RECTORY:  PROCEDURE; 

/****.S:***********:f:*:!c  *************•***********************/ 


/*  DURING  THE  INITIALIZATION  PROCESS  IT  IS  NECESSARY  */ 
/*  TO  DETERMINE  THE  SECTOR  NUMBERS  OF  SEVERAL  SYSTEM  */ 
/*  FILES  WHICH  RESIDE  ON  TIIE  MINI-DISK  IN  SYCOR  FORMAT.  */ 
/*  MULTIPLE  DIRECTORY  SEARCHES  COULD  LEAD  TO  REPEATEDLY*/ 
/*  READ  I NG  THE  SAME  BLOCK  OF  MINI-DISK  SECTORS.  TO  #✓ 

/*  ELIMINATE  MOST  OF  THESE  UNNECESSARY  READ  OPERATIONS  */ 
/*  THIS  PROCEDURE  READS  THE  ENTIRE  SYCOR  DIRECTORY  */ 
/*  INTO  MEMORY  AT  ONE  TIME,  THUS  REDUCING  THE  OVERHEAD  */ 
/*  INVOLVED  IN  MULTIPLE  SEARCHES . */ 

CALLED  BY:  MTSSIPL  */ 

/at***************************************:):******:):*******/ 


[ I NT  SYC0R9D I RSBASEI  /*  SYCOR  DIRECTORY  BASE  */ 

[ SYC0RSDIR8BASE: = 20H1  /*  SECTOR  NUMBER  */ 

DECLARE  MSG  DATA  < ’ CANNOT  READ  DIRECTORY®'  ) ; 

/*  SET  UP  REGISTERS  FOR  DISK  READ  */ 

BC=  [ HEX  SYCORSD I RSBASEI ; 

DE=[ HEX  D I RSBASEI ; 

/*  READ  NUMBER  OF  SECTORS  INDICATED  */ 

/*  IN  DIRECTORY  HEADER  RECORD  */ 

REPEAT; 

l.=  [ READ!  ; CALL  [MINI8DISK3; 

IF  [ D ISKSERRORI  CALL  ABORTS  I PL( . MSG) : 

DE=(  1IL=200H+DE)  ; BC=BC+l; 

UNTIL  C A3 M(  [ HF.X  D I R3BASE+0AH1  ) ; A::C)  CY; 

/*  CALCULATE  ADDRESS  OF  LAST  ENTRY  + I IN  IMAGE  */ 
B= [ HEX  SYCORSD I RSBASE- II ; 
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A= A-B;  /*  A = NR  SECTORS  IN  DIRECTORY  */ 

D=(A=<< A) ; 

E=0 ; /*  DE  = NR  SECTORS  * 512  */ 

MAX= ( HL= t HEX  D I R3BASE+ 1 ] +DE) ; 

END  READ3D I RECTORY; 

SEARCH9D I RECTORY:  PROCEDURE; 

/*#******#***************#********:|:********************,' 
/*  GIVEN  THE  BASE  ADDRESS  OF  A VECTOR  CONTAINING  THE  *y 
/*  NAME  OF  A FILE  IN  SYCOR  FORMAT.  THIS  ROUTINE  WILL  */ 


/*  SEARCH  TUE  DIRECTORY  IMAGE  READ  INTO  MEMORY  BY  */ 

/*  READ8D I RECTORY.  IF  THE  FILE  ENTRY  IS  FOUND,  THE  */ 
/*  BOE  AND  EOE  VALUES  ARE  RETURNED.  */ 

INPUT:  DE  - BASE  ADDRESS  OF  FILENAME  VECTOR  *S 

/*  ASSUMED  TO  BE  8 BATES  LONG  */ 

/*  OUTPUT:  BC  - BOE  OR  FFFFH  IF  FILE  NOT  FOUND  */ 

/*  DE  - EOE  OR  FFFFH  IF  FILE  NOT  FOUND  */ 

/*  CALLED  BY:  INITIALIZE,  RECOVER  */ 


✓*#**#*#**#**********#**#******:;:##**********#****#*****/ 
DECLARE  LOOP  LABEL; 

/*  MOVE  FILENAME  TO  LAST  ENTRY  + 1 *s 
BC=8;  HL=  MAX;  CALL  t MOVBUF3 ; 

DE1  C HEX  DIR3BASF.+4  1 HI  ; /*  ADDRESS  OF  FIRST  ENTRY 
LOOP:  /*  ADVANCE  TO  NEXT  ENTRY  */ 

STACK=DE;  HL=MAX;  B=8; 

REPEAT;  /*  COMPARE  CRAR  BY  CRAR  */ 

IF  ( A=  M(  DE) ; A: : M(  HL) ) ZERO 
N (IF  (A: : 0)  ZERO  < A=M(  HL) -20H)  ZERO 
THEN  CY= I ELSE  CY=0>  CY 
THEN  /*  CHAR  MATCH  */ 

DO; 

DE=DE+ 1 ; HL=  HL+ 1 ; 

END 

ELSE  /*  NON- MATCH  */ 

DO;  DE= STACK: 

DE= ( HL=40H+DE)  : 

GOTO  LOOP; 

END; 

UNTIL  ( B=  B-  1 ) ZERO; 

SP=CHL=2+SP) ; /*  CLEAR  STACK  AS 

/*  FALLING  THRU  LOOP  MEANS  NAMES  MATCH,  */ 

/*  MUST  TEST  FOR  SUCCESS  OR  FAILURE  OF  SEARCH  */ 

IF  ( A- MAX(  1 ) ; A::D)  CY  /*  X::Y=CY=>  X<  Y */ 

\(  IF  ZERO  <A=MAX(0>;  A:  : E)  CY  THEN  CY=  I ELSE  CY=0) 
CY  THEN 

DO;  /#  SEARCH  FAILED  */ 

BC=OFFFFH;  DE= BC: 

END 

ELSE  DO;  /*  SEARCH  SUCCESSFUL 
HL=3+DE; 

C=M( HL) : HL=HL+ 1 ; 

B=  M(  HL)  ; HL=  HL+  I ; 

E=M(  HL)  ; HL=HL+  l ; 

D=M<  HL)  ; 

END; 

END  SEARCH8D I RECTORY; 

RECOVER:  PROCEDURE; 

/****************#:.':*****#********#******#**********#***/' 


y*  MTS  HAS  BEEN  DESIGNED  SO  THAT  THE  SYSTEM  STATE  AT  */' 
ANY  INSTANT  IS  DEFINED  BY  A COMPACT,  CONTIGUOUS  *y 
y * CROUP  OF  BYTES  KNOWN  AS  THE  SYSTEM  STATE  BLOCK.  */ 

/*  EACH  TIME  THAT  SWAPPING  OCCURS  THE  SSB  IS  WRITTEN  */ 

y*  TO  THE  MINI-DISK  FILE  . MTSRCVR.  IF  THE  TASK  JUST  */ 

/*  SWAPPED  IN  CAUSES  A SYSTEM  CRASH,  RECOVERY  IS  */ 

y*  ACCOMPLISHED  BY  RF.EOOTI NG  MTS  AND  .ANSWERING  ’ Y’  TO  */ 
/*  THE  RECOVERY  QUERY.  MTS  WILL  READ  .MTSRCVR  BACK 
/*  INTO  THE  SSB,  DELETE  THE  OFFENDING  TASK,  AND  */ 

/*  CONTINUE  WITH  THE  NEXT  READY  TASK.  *y 

y * NOTE:  THIS  PROCEDURE  USES  TIIE  FACT  THAT  THE  BOE  */ 

/*  AND  EOE  VALUES  RETURNED  BY  SEARCHSD I RECTORY  */ 

/'*  .ARE  EQUAL  FOR  A SINGLE-SECTOR  FILE.  *y 
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/*  CALLED  ay:  MTSSIPL  *S 

/S******:):************************:):*:;:*******************/ 

[ MACRO  BUMP  1 -2  ’ ] 

[ MACRO  OUTSOFSBOUNDS  ’ 7 ’ ] 

/*  FIND  MINI-DISK  SECTOR  ADDRESS  OF  . MTSRCVR  */ 

DE3 .RECSNAME; 

CALL  SEARCII3D I RECTORY : 

IF  (A=B;  A:  : OFFH)  ZERO  CALL  ABORTS  IPL(  . RF.CCNAME)  ; 

/*  READ  . MTSRCVR  INTO  SSB  */ 

HL=I  RECSFILE1 t CALL  [PUT]; 

DE3  C SSBSBASEI ; 

L3  I READ] ; CALL  [MINISDISKI; 

IF  [ DISKS ERROR!  CALL  ABORTS  I PL( . RECSNAME) ; 

/*  DELETE  TASK  CAUSINC  CRASH  */ 

C3  I BUMP] ; 

CALL  IMTSl ; 

E3  [ OUTSOFSBOUNDS] ; 

CALL  [ MTS3MSC]  ; 

END  RECOVER; 

INITIALIZE:  PROCEDURE; 

/*^:*****.-S*«:***»**W*^:lc»:W^*****:K:SS:**W**^:»:!:*****S:*s!:»:*»:*:»**:/' 


/*  THE  SYSTEM  STATE  BLOCK  CONSISTS  OF  THREE  SETS  OF  */ 
/■*  VARIABLES : SYSTEM  CONTROL,  TASK  CONTROL  TABLE,  AND  */ 
/*  THE  DISK  MAP  TABLE.  THE  OBJECT  MODULE  CENERATED  BY  */ 
/*  THE  ML80  COMPILER  CONTAINS  INITIAL  VALUES  FOR 
/*  SYSTEM  CONTROL  VARIABLES  AND  MOST  OF  THE  TCT.  IN  */ 

s*  ORDER  TO  INITIALIZE  THE  REST  OF  THE  TCT  IT  IS  */ 

/*  NECESSARY  TO  SEARCH  TIIE  SYCOR  DIRECTORY  IMAGE  */ 

/*  COPIED  INTO  MEMORY  BY  READS D I RECTORY  FOR  BOE  AND  */ 

/*  EOE  VALUES  FOR  THE  RECOVERY  FILE  AND  ALL  FOUR  SWAP  */ 

/*  FILES.  TO  INITIALIZE  TIIE  DMT  THE  VIRTUAL  DISK  */ 

/*  CONFIGURATION  FILE,  . MTSCNFG,  MUST  BE  READ  INTO 
/*  MEMORY  AND  BOE  AND  EOE  VALUES  FOR  TnE  VIRTUAL  DISK  */ 
r*  FILF.S  EXTRACTED  FROM  TRE  S'/COR  DIRECTORY  IMAGE. 

THE  PROTECTION  ATTRIBUTES  FOR  EACH  VIRTUAL  DISK  *s 
/*  ARE  ALSO  COPIED  INTO  THE  DMT  FROM  .MTSCNFG,  */ 

/*  NOTE:  THIS  PROCEDURE  USES  THE  FACT  THAT  THE  BOE  */ 

/*  AND  EOE  VALUES  RETURNED  BY  SEARCIISD I RECTORY  */ 

/*  ARE  EQUAL  FOR  A SINGLE-SECTOR  FILE.  */ 

s*  CALLED  BY:  MTSSIPL  »/■ 


/'********#***:K:*:***:K:ic****:***:t:W*:l::,l:*****:t:***:t::!:*:)c#:**:lc******,' 

DECLARE  ENTRYSBASEI 2)  BYTE; 

DECLARE  CNFGSNAMEI  9)  BYTE  INITIAL  < ’ . MTSCNFCS ’ ) ; 
DECLARE  SWAPSNAMEI  9)  BYTE  INITIAL  ( ’ . MTSSWPOS ’ ) ; 
DECLARE  SYSDISK(  9)  BYTE  INITIAL  (’SYS  DISKS'); 

/*  SET  UP  RECOVERY  FILE  */ 

DE3 .RECSNAME;  CALL  SEARCHSD I RECTORY; 

IF  <A=B;  A: : OFFH)  ZERO  CALL  ABORTS IPLC . RECSNAME) ; 

HL=  C RECSF ILE]  ; CALL  [PUT]; 

/*  SET  UP  TASK  CONTROL  BLOCK  IN  SSB  */ 

I = ( A= 4) ; STACK3  ( HL3 [ TCTSEOE] ) ; 

REPEAT; 

DE3  . SWAPSNAME ; CALL  SEARCHSD  I RECTORY; 

IF  ( A=B;  A:: OFFH)  ZERO 

CALL  ABORTS IPL(  .SWAPSNAME)  : 

/'*  CHECK  THAT  SWAP  FILE  AT  LEAST  16K  */ 

L-< A' TC.+l) ; H3< A3 !B,++0) ; 

HI.-  IIL+DE; 

IF  (A=L;  A: : 3 1 ) CY  CALL  ABORTS  I PL(  . SWAPSNAME) ; 
HL- STACK;  CALL  [ POT]  ; 

DE=BC;  BC=-9; 

HI.MIL+BC;  CALL  [POT]; 

BC=9;  STACK3  ( HL=HL+BC) ; 

SWAPSNAMEI  7) 3 ( A=SWAPSNAME(  7)  + 1 ) ; 

UNTIL  (I»(A=I-1))  ZERO; 

SP=(HL*2+SP) ; /*  CLEAR  STACK  */ 

/■A-  SET  UP  DISK  MAP  TABLE  IN  SSB  *S 
DE3 . CNFC8NAME ; CALL  SEARCnSD I RECTORY; 

IF  (A=B;  A: : OFFH)  ZERO  CALL  ABORTS  I PL(  . CNFGSNAME) ; 
HL3 [ CNFGSF ILEI ; CALL  [POT]; 

/*  READ  CONF I CURAT I ON  FILE  INTO  MEMORY  */ 
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DE= [ MENS BASE] s L=  C READ! j CALL  C MIN  I SD ISKI  ; 

IF  [ DISKSERRORJ  CALL  ABORTS  I PL( . CNFCSNAME) ; 
I«(A=0);  ENTRYSBASE- < HL- < DE- [ IIEX  MEMSBASE  ♦ 21))! 
REPEAT;  /*  STEP  THRU  CONF I CURAT I ON  FILE  */ 

CALL  SEARCHED  I RECTORY; 

IF  ( A-B;  A:  : OFFII)  IZERO  THEN 

DO;  /*  VIRTUAL  DISK  (I)  EXISTS  */ 

STACK3  DC ; B=0;  C=(A*<<I); 

HL=t DMTSEOE1+BC;  CALL  [PUT]; 

DE- STACK;  HL-  [ DMT8B0E] +BC ; CALL  [PUT!; 
BC-B;  DE- ( HL- ENTRY8BASE* BC) ; 

B-O;  C*(Aa<<(A-<< I)) i 
HL-  [ DMTS5KEY1  + BC ; 

DO  B-0  BY  B=  B+ 1 WniLE  (A-B-4)  IZERO; 

N(IIL)  = ( A=M(  DE)  ) ; 

DE-  DE+  1 ; HL-  IIL+  1 ; 

END; 

B=0;  C-CA-I); 

HL-  I DMTSFLAG] +BC ; 

IF  (A-M(DE);  ZERO  THEN 

MC  HL) -ODH 
ELSE  DO; 

IF  ( A : : ( B=  ’ P ' ) ) ZERO  THEN  M(HL)=05H 
ELSE  M(  HL) =0 1H: 

END; 

END; 

DE=  ( HL-  ENTRYSBASE+ ( BC-  1 3)  ) ; 

ENTRYSBASE-  HL; 

UNTIL  ( I = ( A-  I + 1 ) ; A::32)  ZERO; 

/*  CHECK  THAT  DISK  0 EXISTS 
HL-  [ DMTSFLAG]  : 

IF  (A-M(HL)  01)  ZERO  CALL  ABORTS  IPL(  . SYSDISK)  ; 
END  INITIALIZE; 


MTS8IPL: 

/*******:r**:#:i::)::K:K***:;:********:t::!:*****$*:S*S*:S:t::S****:.l:**:S***/ 


/*  THIS  ROUTINE  IS  THE  INITIAL  ENTRY  POINT  INTO  MTS.  */ 
/*  THE  SYCOR  440  LOADER  TRANSFERS  CONTROL  HERE  AFTER 
/*  THE  SYSTEM  OBJECT  MODULE  HAS  BEEN  LOADED.  DURINC  */ 
I PL  ALL  PERIPHERAL  DEVICES  ARE  RESET.  TIIEN  MTS 
/*  READS  THE  SYCOR  DIRECTORY  INTO  MEMORY,  AND  ASKS 
/*  THE  OPERATOR  AT  TERMINAL  0 WHETHER  RECOVERY  IS  */ 

/*  REQUIRED.  IF  THE  ANSWER  IS  ' Y’  THEN  THE  PROCEDURE  */ 
/%  RECOVER  IS  CALLED  TO  READ  THE  FILE  . MTSRCVR  INTO  */ 
/*  THE  SYSTEM  STATE  BLOCK.  OTHERWISE  THE  PROCEDURE  */ 
INITIALIZE  IS  CALLED  TO  BUILD  AN  SSB  FROM  I NFOR- 
/*  MAT ION  CONTAINED  IN  THE  SYCOR  DIRECTORY  IMAGE  AND  */ 
/*  THE  FILE  . MTSCNFG.  ONCE  IFL  IS  COMPLETE  CONTROL  IS 
/*  TRANSFERRED  TO  THE  PFiOCESSOR  MANAGEMENT  SUBMODULE  *s 
/'*■  WHICH  WILL  CONTROL  ALL  SUBSEQUENT  PROCESSING.  */ 

/*  CALLED  BY:  SYCOR  SYSTEM  LOADER  */ 


/********************:<:*****:S*:|::K:K**:*:f:Ms:fc*:.':****»:**X***X:|t*x/ 
DECLARE  (WAIT,  TEST)  LABEL; 

DECLARE  IPL8MSC( 15)  BYTE  INITIAL  ( ’ RECOVERY"  ( Y/N) ' ) ; 
/*  SET  STACK  POINTER 
DE-CTOP] ; 

SP= ( HL- I SYSSSTACK]  + DE)  ; 

/*■  CLEAR  PERIPHERAL  INTERRUPTS  */ 

[DISABLESTIMER]  : 

[ CLEARSCSST8 I NT]  ; 

[ CLEARSPRNTS I NT] ; 

/*  CLEAR  STATUS  LINE  ON  ALL  TERMINALS  */ 

DO  1°  < A*  9)  BY  IMA-I+l)  WHILE  ( A- I ; A::4>  IZERO; 

CALL  [CLEARSSTATUS8LINEI  ; 

END; 

/*  READ  SYCOR  DIRECTORY  INTO  MEMORY  */ 

CALL  READSD I RECTORY; 

D rSPLAY  rPLSMSG  AT  TERMINAL  0 */ 

BC-15;  DE= . IPLSMSG;  HL-0700H: 

CALL  [ MOVBUF] ; 

/*  ENABLE  INTERRUPTS  SO  TERMINAL  MODULE  MAY  */ 

/*  BE  USED  TO  PROCESS  REPLY  TO  IPLSMSG  */ 
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ENABLE; 

[RF.SETSTIMER] ; 

/*  PROCESS  OPERATOR’ S REPLY  */ 

WAIT:  REPEAT; 

CALL  [ TERM I N ALSSTATUS  3 ; 

UNTIL  (A::0>  I ZERO; 

CALL  [READSTERJ1INAL]  ; 

I = A; 

IF  C A:  •'  ODH)  ZERO  GOTO  TEST; 

REPEAT; 

CALL  [READSTERTIINAL]; 

UNTIL  (A::ODU)  ZERO; 

TEST: 

IF  < A= I ; A: : ( B= ’ Y’  ) ) ZERO 
\ ( A:  : ( B=79H) ) ZERO 
THEN  CALL  RECOVER 
ELSE  DO; 

IF  (A: : ( B=  * N ' ) ) ’ZERO 
( A: : ( B=6EH) ) IZERO 
THEN 

DO;  E= ’ ? ’ ; 

CALL  [ WRITESTEIU1INAL]  ; 

GOTO  WA I 1 t 
END 

ELSE 

DO; 

CALL  INITIALIZE; 

A=0;  CALL  [ CLF.ARSSTATUSSLINE]  ; 
END; 

END; 

GOTO  [MONITOR]; 

/*  END  MTS3IPL  */ 


EOF 
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✓ ************:*************:*:****************************/ 
/*  SERVICE  MODULE  */ 

SXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX  XXXX  xxXXXXXXS 


/*  *s 
sx  THIS  MODULE  PROVIDES  THE  INTERFACE  BETWEEN  THE  */ 
SX  USER  AND  ALL  SYSTEM  SERVICES.  THESE  SERVICES  FALL  *' 
s*  GENERALLY  INTO  TWO  CATEGORIES:  */ 


/*  *s 
sx  (1)  SYSTEM  CALLS  - THOSE  FUNCTIONS  REG J I RED  TO  */ 
/*  ESTABLISH  THE  DESIRED  VIRTUAL  MACHINE  */ 
/*  ENVIRONMENT.  */ 
sx  */ 
Sx  (2)  SERVICE  CALLS  - THOSE  FUNCTIONS  REQUIRED  TO  */ 
sx  ACCESS  THE  VIRTUAL  DEVICES  PROVIDED  BY  THE  */ 
SX  VIRTUAL  MACHINE  ENVIRONMENT.  */ 
/*  xs 
Sx  SYNTACTICALLY  THE  TWO  TYPES  OF  PROCEDURE  CALL  ARE  */ 
/*  IDENTICAL,  I.E.  */ 
/«  VALUE  = MTSC  FID,  FARM)  . */ 
sx  EACH  CALL  TAKES  TWO  ARCTJMENTS , FID  IN  REGISTER  C */ 
sx  AND  PARM  IN  REGISTERS  DEj  -AND  RETURNS  A VALUE  */ 
sx  IN  THE  A REGISTER.  THE  FORM  OF  THE  ARGUMENTS  AND  */ 
sx  THE  SIDE  EFFECTS  .ASSOCIATED  WITH  EACH  DIFFERENT  */ 
/*  FUNCTION  ARE  DISCUSSED  IN  MORE  DETAIL  IN  HIE  MTS  */ 
SX  USER'S  MANUAL.  NOTE  HOWEVER  THAT  THE  ARGUMENT  REC-  */ 
/*  ISTER  ASSIGNMENTS  CONFORM  TO  THE  PL/M  CONVENTION  */ 
/*  FOR  PASSING  PARAMETERS.  THE  FOLLOWING  TABLE  SUM-  */ 
/x  MARIZES  THE  ARGUMENT  OPTIONS  AND  CORRESPONDING  */ 
/*  RETURNED  VALUES.  */ 


/* 

/*  FID  NAME 


PARM  VALUE 


*/ 

*/ 

xs 


SX 

— 

SYSTEM 

CALLS  

/X 

0 

ATTACH 

LIST 

ERROR 

/X 

i 

DISPLAYSNSG 

ERROR 

NONE 

/X 

2 

LOGIN 

LIST 

ERROR 

/X 

3 

PROTECT 

LIST 

ERROR 

SX 

4 

QUIT 

NONE 

NONE 

SX 

5 

RESTRICT 

LIST 

ERROR 

/X 

6 

SIZE 

SIZE 

ERROR 

/X 

7 

UN PROTECT 

LfST 

ERROR 

L,  A 1 . 1— ■ o 

/X 

8 

TERM I HALSSTATUS 

NONE 

TRUE/FALSE 

/X 

9 

READSTERM INAL 

NONE 

CHARACTER 

SX 

10 

WRITESTERMI  NAL 

CHARACTF.R 

NONE 

/* 

1 1 

WRITE8PRI NTER 

CHARACTER 

ERROR 

/X 

12 

SELECTSDRIVE 

DRIVE  NR 

ERROR 

/X 

13 

SETSDMA 

DMA  ADDRESS 

ERROR 

/X 

14 

SETSTRACK 

TRACK  NR 

NONE 

/X 

15 

SETSSECTOR 

SECTOR  NR 

ERROR 

/X 

16 

READ3FL0PPY 

NONE 

ERROR 

SX 

17 

WHITE8FLOPFY 

NONE 

ERROR 

X/ 

X/ 

X/ 
xs 
xs 
xs 
xs 
x s 
*s 

X S 

xs 

xs 

xs 

xs 

XS 

XS 

xs 

xs 

xs 


/*  xs 
sx  IN  THIS  TABLE  THE  ENTRY  ’LIST’  UNDER  PARM  INDICATES*/ 
/*  THAT  THE  ACTUAL  ARGUMENT  IS  THE  ADDRESS  OF  A LIST  */ 
/*  OF  REQUIRED  PARAMETERS . WHEN  'NONE'  APPEARS  UNDER  xs 
SX  THE  SAME  HEADING,  IT  MEANS  THAT  THE  PARM  ARGUMENT  */ 
/*  IS  NOT  REQUIRED.  IF  'NONE'  APPEARS  UNDER  VALUE  THE  xs 


/* 

ERROR 

CODE 

RETURNED  IS  ALWAYS  ZERO.  THE  ENTRY 

X S 

/* 

’ERROR'  INDICATES  THAT  AN  ERROR  CODE  IS  RETURNED. 

xs 

/% 

THESE 

CODES 

ARE  DEFINED  AS  FOLLOWS: 

X/ 

/X 

X/ 

/X 

CODE 

ERROR 

X S 

/X 



X S 

/"X 

0 

OPERATION  SUCCESSFUL 

Xs 

/X 

1 

INVALID  COMMAND 

xs 

/X 

o 

DISK  NOT  AVAILABLE 

X/ 

/X 

3 

DISK  IN  USE 

X/ 

/X 

4 

DISK  NITMBER  ERROR 

X/ 

/X 

3 

KEY  ERROR 

X/ 

/X 

6 

DRIVE  LETTER  ERROR 

X/ 

/* 

7 

OUT  OF  BOUNDS 

xs 
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8 

HARDWARE  ERROR 

X/ 

/X 

9 

PROTECTION  ERROR 

X/ 

/X 

10 

DRIVE  NOT  AVAILABLE 

X/ 

/X 

X/ 

SX 

THE 

SERVICE  MODULE 

IS  DIVIDED  INTO  THREE  BASIC 

X / 

/X 

SUBMODULES: 

X/ 

/X 

X/ 

/X 

( 1) 

USER  INTERFACE 

X/ 

/X 

THIS  SUBMODULE 

CONTAINS  TTIE  ENTRY  POINT  INTO 

X/ 

/X 

THE  SERVICE  MODULE  FROM  MCP  AND  USER  PRO- 

X/ 

/X 

GRAMS.  IT  IS  HERE  THAT  THE  SERVICE  REQUEST 

X/ 

/X 

IS  INTERPRETED 

AND  THE  APPROPRIATE  SERVICE 

X/ 

/X 

ROUTINE  CALLED 

FOR  EXECUTION. 

X/ 

/X 

X/ 

/X 

(2) 

SYSTEM  CALLS 

X/ 

/X 

THIS  SUBMODULE 

CONTAINS  THE  SERVICE  ROUTINES 

X/ 

/X 

AND  SUPPORTING 

PROCEDURES  WHICH  CREATE  OR 

X/ 

/X 

MODIFY  THE  USER’S  VIRTUAL  ENVIRONMENT. 

X/ 

THESE  ROUTINES  ARE  INVOKED  DY  NCR  IN  RESPONSE  */ 
/-*  TO  SYSTEM  COMMANDS  ENTERED  AT  A TERMINAL.  */ 

/*  THEY  MAY  ALSO  BE  ACCESSED  BY  USER  PROGRAMS  */ 

/*  DIRECTLY  THROUGH  THE  USER  INTERFACE  SUBMODULE. */ 

/%  */ 

/*  (3)  SERVICE  CALLS  */ 

THIS  SUBMODULE  CONTAINS  SERVICE  ROUTINES  AND  */ 

SUPPORTING  PROCEDURES  WHICH  ALLOW  A USER  */ 

/*  PROGRAM  TO  ACCESS  A VIRTUAL  TERMINAL  OR  */ 

/x  VIRTUAL  FLOPPY  DISK.  */ 

/%  */ 


/ x * * :fc  rf:  X XXX  X X X X X X X X XXXX  X X X X X X X X XXXXX  X X X X X X X X X X X X XX  X XX  X / 
/XXXXXXX X X X X X X X XX XX X X X X X X X X X X X X X X X X X X X X X X X XXXX X X X X XXX XX/ 


/*Xcx;xeXi*m':*.ti**X*XXXXX:X*XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/' 

/xxxxxxxxxxxxxxxxxxx  USER  INTERFACE  xxxxxxxxxxxxxxxxxxx/ 

/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/ 


/***X*X#X-J!****  INTERMODULE  LINKAGE  MACROS  xxxxxxxxxxxx/ 

t INT  ME  TB  M2B1  [M2B:=O6O0HI  [ MB : = 03OOH3  [TB:=10C8H] 

[ INT  32B  S3B]  [S2B:=220OH]  CS3B:=2600HI 

[MACRO  MONITOR  ’[HEX  MB  +8FHI ’ i 
[MACRO  INDEX  ’ C HEX  M2B  + 3HI  ’ I 
[MACRO  ATTACH  ’[HEX  S2B  + 14AHI ' ] 

[MACRO  LOGIN  ’[HEX  S2B  + 208III  ’ I 
[ MACRO  PROTECT  ’ [ HEX  S23  + 25CHI ’ I 
[MACRO  OUIT  ’[HEX  S2B  + 261HI’] 

[MACRO  BUM?  ’[HEX  S2B  + 293H3 ’ 1 
[MACRO  RESTRICT  ’[HEX  S2B  + 2C21II  ’ 1 
[MACRO  SIZE  ’[HEX  S2B  + 2C7HI ’ I 
[MACRO  UNPROTECT  ’[HEX  S2B  + 31FHI’] 

[MACRO  VRITESPRINTER  ’[HEX  S3B  + 0EDH] ’ ] 

[MACRO  SELECT3DRIVE  ’[HEX  S3B  + 0F2IIJ  ’ I 
[MACRO  SET8DMA  ’[HEX  S3B  + 15FHI’] 

[MACRO  SETSTRACK  ’ [ HEX  S3B  + 17CHI ’ ] 

[MACRO  SETSSECTOR  ’[HEX  S3B  + 186HI ’ I 
[ MACRO  READ8FL0PPY  ’ [ nEX  S3B  + 1 AOU1 ’ I 
(MACRO  WRITESFLOPFY  ’[HEX  S3B  + 1B4H]’] 

( MACRO  MTSSMSG  ’ [ HEX  TB  + 837HI  ’ ] 

[MACRO  TERM  I NALSSTATUS  ’ [ HEX  T3  + 8D2HI  ’ I 
[MACRO  BEADSTERMI NAI.  ’[HEX  TB  + 8DCH1  ’ I 
[MACRO  WR I TESTE  RM  INAL  ’[HEX  TB  + 93CH] ’ 3 

/xxxxxxxxxxxxxxx  CENERAL  PURPOSE  MACROS  *X».X*X**XH:**>'*X/ 


[ INT  TOPI  [TOP: =203 
[ MACRO  I NPUT3VA I T I NC  ’ OFFH ’ ] 

/XXXX*****XX*X*XX*XZ*  DECLARAT I OIIS  XXXXXXXXXXXXXXXXXXXXS 
DECLARE  ( MTSS EXTERNAL,  MTSS INTERNAL,  EXIT, 
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INTERNALSMTS:  /*  INTERNAL  ENTRY  POINT  INTO  SERVICE  */ 

/*  NODULE,  I.E.  ENTRY  POINT  FROM  */ 
/■>■  OTHER  MTS  ROUTINES  */ 

SAVE(  2)  = ( A- LOCK) i /*  SAVE  LOCK  VALUE  */ 
PARM=(HL=DE)  ; /*  SAVE  PARM  LIST  ADDRESS  */ 

SAVE=(HL=0+SP) ; SAVE  USER  SP 

SP= ( HL= . SVCSSTACKC  C TOPI ) ) ; 

IF  ( A=<  < C)  ICY  GOTO  MTS; 

A=(A=!C)+1;  /*  CONVERT  FID  TO  POSITIVE  NR  */ 

IF  (A: :3)  ICY  THEN 

/*  INVALID  COMMAND  - ERROR  1 
DO;  ERROR=  ( A= 1 ) ; GOTO  EXIT;  END; 

H=0;  L=  A; 

DO  CASE  HL; 


/*  0 */ 

DO;  NOP;  END; 

- 1 

DO;  CALL  [ READSTEPJ1INAL3 

ERROR1 A ; 

END; 

/*  -2  */ 

CALL  [BUMP]; 

/*  CASE 

*/ 

GOTO  EXIT; 


toon:  /*  ADJUST  EXTERNAL  ENTRY  POINT  LOCATION  *■/ 

EXTERNALSMTS:  /"»  EXTERNAL  ENTRY  POINT  INTO  SERVICE  */ 

/*  MODULE,  I.E.  ENTRY  POINT  FROM  */ 

USER  PROGRAMS  */- 

DISABLE; 

SAVE!  2)  = ( A=  LOCK  OFEII)  ; /*  SAVE  LOCK  VALUE  */ 

LOCK=  ( A= A s 01);  /*  LOCK  OUT  SVAPPINC  */ 

ENABLE; 

PARM=  ( HL=  DE) : /*  SAVE  PARM  LIST  ADDRESS 


SAVE=(  HL=0+SP)  ; SAVE  USER  SP  «✓ 


SP= ( HL= . SVCSSTACKC  [ TOP]  ) ) ; 


MTS:  /■»  SYSTEM  AND  SERVICE  ROUTINES  */ 

IF  (A=C;  A: : 18)  ICY  THEN 

INVALID  COMMAND  - ERROR  1 
DO;  ERROR= ( A= 1 ) ; COTO  EXIT;  END; 

ERR0R=(A=0>;  /*  INITIALIZE  RETURNED  ERROR  CODE  */ 

H=0;  L=C; 

DO  CASE  HL; 

SYSTEM  CALLS  *******»:»**#*:,':**,' 


/* 

o 

*/ 

CALL 

C ATTACH] ; 

/X 

i 

X/ 

CALL 

[ MTS3MSG]  ; 

/X 

2 

X/ 

CALL 

[LOGIN] ; 

/* 

3 

•*/■ 

CALL 

[ PROTECT] ; 

/* 

4 

X/ 

CALL 

[QUIT] ; 

/X 

3 

X/ 

CALL 

[RESTRICT]  ; 

/* 

6 

X/ 

CALL 

[SIZE] ; 

/* 

7 

X/ 

CALL 

[UNPROTECT] 

/a;*****#*  SERVICE  CALLS  *#X***X********/ 

/*  8 */  DO;  CALL  [ TERMINALSSTATUS] ; 

ERROR1 A ; 

END; 

/*  9 *S  DO;  CALL  [ TERMINALSSTATUS] ; 

IF  ( A: : C INPUTSWAITING] ) ZERO  THEN 
DO;  CALL  C RE ADS TERM INAL 1 ; 
ERROR= A; 

END 

ELSE  GOTO  TERMSBLOCX; 

END; 

/*  10  */  CALL  ( VRITESTERMINAL]  : 

/r.  II  */  CALL  [WRITESPR INTER]  : 
z'*  12  CALL  C SELECTSDRIVE3  ; 

/*  13  */  CALL  [ SET8DMAJ  ; 

/*  1 4 CALL  [ SETSTRz\CKI  ; 

/*  1 3 «/  CALL  [ SET3SECT0R] ; 
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/*  16  */  CALL  [ READSFLOPPY] ; 

/*  17  */  CALL  [WRITESFLOPPV]  i 
END;  CASE  */ 

EXIT:  COMMON  EXIT  POINT  FOR  INTERNAL  AND  EXTERNAL 

SP=  ( HL=SAVE)  ; /*  RESTORE  USER  SP  */ 

DISABLE; 

LOCK1 < A=SAVE(  2) ) ; RESTORE  LOCK  VALUE  */ 

A= ERROR; 

ENABLE; 

RETURN ; 

/*  END  MTS  */ 

TF.RMSBLOCK: 

/***********************************************:*******.' 


/*  THIS  ROUTINE  IS  CALLED  WHEN  THE  TASK  CURRENTLY  */ 

s*  ALLOCATED  THE  CPTJ  IS  BLOCKED  FOR  TERMINAL  \st>.  THE 
/*  ROUTINE  STORES  THE  CURRENT  MACHINE  ENVIRONMENT  IN  */ 
/*  THE  SWAP  STACK  AND  TRANSFERS  CONTROL  TO  THE  */ 

/%  MONITOR  FOR  SELECTION  OF  THE  NEXT  READY  TASK.  */ 

/*  CALLED  BY:  MTS  */ 


/*XX**J:XXX#%:l:X*%#XXX******#*X*XX:X*#**#***%X#X##XXXXX***/ 
/*.  SET  BIT  5 IN  TCTSSTATU3  a:/ 

DE=  . TCTDSTATUS  ; A- TASK;  CALL  C INDEX]  ; 

HI  ILL)  - ( A3M(  HL>  \ 20H)  ; 

SAVE  ENVIRONMENT  */ 

SWAP3STACK-  ( HL=SAVE) ; ONLY  USER  SP  NEEDED 

COTO  [MONITOR]; 

END  TERHCBLOCK 


EOF 

/**»«****  ***  *:aca:ata::.':a:  ««*««**  **  J.t  xxmex/ 

SYSTEM  CALLS  xxxxxxxxxxxxxxxxxxxx/ 
sxx**xx*xxxx***xx:**-.K*xx****Xm*--K***%'X'xx****x***x****'-*****S 


/*x±**:K*xxx.xx*  INTERMODULE  LINKAGE  MACROS  xxxxxx*##***/' 

[HIT  TB  MB  M2 3 1 [ M2B: =0600H]  [T3:=1000H]  CMB;=0300HJ 

[MACRO  MONITOR  ’[HEX  MB  + 8FH] * j 
[MACRO  INDEX  ’[HEX  M2B  + 3H]  ’ I 
[ MACRO  INDEX2  ’[HEX  M2B  + ODHJ ’ ] 

[MACRO  INDEX4  ’(HEX  M2B  + 18H]  ’ ] 

[MACRO  INDEX8  ’[HEX  N2B  + 24H]  ’ I 
[ MACRO  GET  ’ C HEX  M2B  + 38III  ’ I 
[MACRO  MOVBUF  ’[HEX  M2B  + 4 1HI’] 

[MACRO  MINISDISK  ’[HEX  M2B  + 54H] ’ I 
[MACRO  SIZESMSG  ’[HEX  TB  + 864U] ’ ] 

[ MACRO  STATUS8MSG  ’ [ IIEX  TB  + 88CHI  ’ ] 

[MACRO  CLEARSSTATUSSLINE  ’[HEX  TB  + 827H1 ’ I 
[ MACRO  MTSSMSG  ’ [ HEX  TB  + 837HI ’ I 

/XXXXXXXXXXXXXXX  GENERAL  PURPOSE  MACROS  ***************/ 

[MACRO  WRITE  ’2’] 

[MACRO  HARDWARES ERROR  ’8’ I 


^**w*******.-)t***:r.*****  DECLARATIONS  a:*atat****ata:a!*a:*a:a:**at*,' 


DECLARE  PLIST  DATA  (1,0, OFFH, OFFH, OFFH, OFFU) : 

rxxxxxx  UTILITY  PROCEDURES  a:****************/' 
VALS DRIVE:  PROCEDURE; 

THIS  PROCEDURE  VALIDATES  THE  DRIVE  NUMBER  INPUT  TO  */ 


/%  ANY  SYSTEM  CALL  WHICH  REQUIRES  THAT  PARAMETER.  */ 

INPUT:  A - DRIVE  HUMBER  TO  BE  VALIDATED  *s 

/*■  OUTPUT:  DRIVE  - NUMBER  OF  FREE  DR  I ATS  FOUND  */ 

/*  ERROR  - ERROR  CODE  *s 

/*■  CALLED  BY:  ATTACH  */ 
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IF  ( A: : 0FFH)  ZERO  THEN  /*  NO  DRIVE  SPECIFIED  */ 
DO;  s*  SCAN  DRIVE  NAP  FOR  FREE  DRIVE 
DECLARE  LI  LARFL; 

DE3  . TCTPP'.;  A3  TASK;  CALL  [ INDEX8I ; 

B3i); 

REPEAT; 

IF  C A=<II(  EL)  ) ICY  GOTO  LI; 

1£L=  HL+  1 ; 

UNTIL  <B=B-1)  ZERO; 

/*  NO  DRIVE  AVAILABLE  - ERROR  10  »/ 
ERROR3  ( A=  10)  ; RETURN ; 

LI:  DRI  VE=  ( A=8-B)  ; /*  FREE  DRIVE  FOUND  »/ 

END 

ELSE  IF  (A: : 8)  ICY  THEN 

DRIVE  NR  > 7 - ERROP.  6 
DO;  ERROR-1  A=6>;  RETURN;  END; 

END  VALS DRIVE; 

VALSDISK:  PROCEDURE: 

S»  THIS  PROCEDURE  VALIDATES  THE  DISK  NUMBER  INPUT  TO 


z*  ANY  SYSTEM  CALL  ’.-.RICH  REQUIRES  THAT  PARAMETER.  */ 
/■*  INPUT:  A - DISK  NUMBER  TO  BE  VALIDATED  */ 
/x  OUTPUT:  DISK  - NUMBER  OF  FREE  DISK  FOUND  */ 
/*  ERROR  - ERROR  CODE  *-/ 
/*  CALLED  BY:  ATTACH 


IEC  A : : OFFH)  ZERO  THEN  /*  NO  DISK  SPECIFIED 
DO;  /»  SCAN  DISK  MAP  FOR  FREE  DISK  '*/ 

DECLARE  L2  LABEL: 

HL3 . DMTSFLAG;  B332; 

REPEAT; 

IF  ( A=>  FK  HL)  ) CY  /*  DISK  AVAILABLE  */ 

( A=>  A)  'CY  /*  NOT  IN  USE  */ 

( A=>  A)  ICY  /*  NOT  PROTECTED  */ 

(A-)A)  ICY  NOT  RESTRICTED 

THEN  GOTO  L2; 

HL-  HL+  1 ; 

UNTIL  ( B=  B— I ) ZERO: 

/*  NO  DISK  AVAILABLE  - ERROR  2 X/ 

ERROR3 ( A=2>  ; RETURN : 

L2 : DISK3! A=32-B> ; /*  FREE  DISK  FOUND  */ 

END 

ELSE  IF  (A:: 32)  ICY  THEN 

D I SK  NR  > 3 1 - ERROR  4 
DO;  ERROR3  (A=4);  RETURN;  END 

ELSE 

DO;  /*  SEE  IF  SPECIFIED  DISK  AVAILABLE  */ 
DE3- DMTSFLAG;  A3DISK:  CALL  [INDEX]; 

IF  (AOIKHL))  ICY  THEN 

/*  DISK  NOT  AVAILABLE  - ERROR  2 */ 

DO:  ERROR3  (A3  2);  RETURN;  END; 

IF  ( A3  > A)  CY  THEN 

DISK  IN  USE  - ERROR  3 */• 

DO ; ERROR3 1 A3  3 ) ; RETURN ; END ; 

END; 

END  VALSDISK; 

VALSKEY:  PROCEDURE; 

/*************'*******s***:s**************l:s*****x***s***/ 


/*  THIS  PROCEDURE  COMPARES  TIIE  KEY  INPUT  AS  A SYSTEM  */ 
/*  CALL  PARAMETER  WITH  THAT  ASSOCIATED  WITH  A SPECI-  */ 
/-*  F I ED  VIRTUAL  DISK  FILE.  */ 
/*  INPUT:  PARM  - VARIABLE  HOLDING  ADDRESS  OF  PARM  KEY  *s 
/*  DISK  - VIRTUAL  DISK  KILE  NUMBER  */ 
/*  OUTPUT:  ERROR  - ERROR  CODE  */ 
/*  CALLED  BY:  ATTACH  */ 


DE=  . DMTSKEY:  A=D!SK;  CALL  C IHDEX4]  ; 

DE3  IM:  HL3  PARM: 

DO  B30  BY  B’Bf!  WHILE  <A=4;  A:  : B)  17.ER0; 
IF  < A3  Mt  DE)  ; A::M(IH.))  ZERO 
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\ (IF  ( A:  : 20H)  ZERO  ( A=M(  HL) -OFFH)  ZERO 
THEN  CY=  I ELSE  CY=0)  CY 
THEN  /*  CHAR  HATCH 
DO; 

DE=  DE+ 1 ; HL=HL+I; 

END 

ELSE  XX  KEY  ERROR  - ERROR  3 *x 
DO;  ERRCR=  ( A=  5 ) ; RETURN;  END; 

END;  /*  WHILE 
/*  KEYS  MATCH  *✓ 

END  VAL3KEY; 

CLEARS FLAG:  PROCEDURE; 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

/*  THIS  PROCEDURE  RESETS  THE  IN  USE  BIT  (BIT  1)  IN  */ 

XX  THE  DMTSFLAG  FOR  A SPECIFIED  VIRTUAL  DISK.  */ 

XX  INPUT:  B - DISK  NUMBER  XX 

XX  CAI.LED  BY:  ATTACH,  LOGIN,  CLEARS  DM  XX 

/***Sc***S;***3:******Sc:k«#«»***S:***»:*************X*S:9:9:****/ 

DE=  .DMTSFLAG;  A=B  1FH;  CALL  (INDEX); 

M(  nL)  = ( A=M(  HL)  OF  DID  ; 

END  CLEARSFLAG; 

CLEARSDM:  PROCEDURE; 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
XX  THIS  PROCEDURE  RESETS  ALL  ENTRIES  IN  THE  TCTSDfl  *x 

/*  ASSOCIATED  WITH  THE  CURRENT  VALUE  OF  TASK.  *✓ 

XX  CALLED  BY:  LOGIN,  QUIT  X/ 

/X  x:: ■ XX  XXXXXX  XX  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
DE=  . TCTSDM:  A=TASK;  CALL  [ INDEXSI  ; 

M(HL)=OCOH;  C=7; 

REPEAT; 

HL= HL+  1 ; 

B=M(HL);  I1(HU=0; 

IF  ( A=  < B ) CY  ( A-  < A)  ICY  THEN 
CALL  CLEARSFLAG: 

UNTIL  (C=C'1>  ZERO; 

END  CLEARSDM; 

WRITESBUF:  PROCEDURE; 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

/*  THIS  PROCEDURE  CHECKS  THE  MODIFICATION  BIT  IN  */ 

/*  VDCSDRIVE  TO  DETERMINE  IF  THE  CONTENTS  OF  MDBUF  »/ 

XX  HAVE  BEEN  ALTERED.  IF  SO,  THE  BUFFER  IS  WRITTEN  TO  xx 

XX  THE  MINI-DISK  AND  THE  MOD  BIT  IS  RESET.  X/ 

XX  CALLED  BY:  QUIT.  MAP,  LOGIN  */ 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
IF  ( A=<  VDCSDRIVE)  ICY  RETURN; 

BC=  ( EL=  MDSAD)  ; BE=  . MD3UF  : 

L= I WRITE];  CALL  [ MIN  ISDISKI  ; 

IF  (A:  : 0)  IZERO  THEN 

/X  HARDWARE  ERROR  - ERROR  8 */ 

DO;  ERROR- ( A- 8 ) ; RETURN;  END; 

VDCSDRI VE= ( A- VDCSDRIVE  7FH) ; 

END  WRITESBUF; 

/xxxxxxxxxxxxxxxxxx  SYSTEM  ROUTINES  xxxxxxxxxxxxxxxxxxx x 


ATTACH:  PROCEDURE; 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
XX  SIMULATE  THE  PHYSICAL  OPERATION  OF  LOADING  DISK  */ 
XX  < DISK  NR>  INTO  DRIVE  < DRIVE  LTR> . XX 

xx  ARGUMENTS:  xx 

/X  (1)  F ID  = 0 X/ 

/X  (2)  PARM  = BASE  ADDRESS  OF  PARAMETER  LIST  */ 

/»  BYTE  0:  DRIVE  NUMBER  (0-7)  X/ 

/X  BYTE  i:  DISK  NUMBER  (0-31)  */ 

/x  BYTES  2-5:  PROTECTION  KEY  (0-4  CILARS)  */ 

xx  VALUE:  ERROR  CODE  xx 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

BC=(HL=PARM)  ; DR!  VE=  ( A=M(  BC)  ) ; 

/X  VALIDATE  DRIVE  NR  */ 


179 


CALL  V.AL3DRIVE:  IF  (A® ERROR  \ A)  IZERO  RETURN; 

HL=  PARM+  1 ; DISK®  < A=M(  HL)  > : 

/*  VAI.1DATE  DISK  NR  */ 

CALL  VALSDISK;  IF  (A® ERROR  \ A)  ! ZERO  RETURN; 

DE=  . DMT9FLAC;  A®  DISK;  CALL  [INDEX]; 

IF  ( A®  M(  HL)  0411)  I ZERO  THEN  /*■  DISK  PROTECTED  x/ 
DO;  /*  VALIDATE  KEY  */ 

PARTI®  ( IIL=  PARTI+  1 , + ! ) ; CALL  VALSKEY; 

IF  (A® ERROR  \ A)  !ZERO  THEN 

DO;  /*  HAY  WANT  READ  ONLY 

DE®  . DTrTSFLAG;  A=DISK;  CALL  [INDEX];  BC=HL; 

IF  (A®  MOIL)  08H)  ZERO 

DISK  NOT  RESTRICTED  xs 
S ( IIL=  PARTI;  A®  PIC  IIL)  ; A::OFF!I>  * ZERO 
/'*  KEY  PARTI  NON- BLANK  X/ 

THEN  RETURN  /*  ERROR  VALID  */ 

ELSE 

DO;  /*  SET  UP  READ  ONLY  */ 

M(BC)  = (A=H(BC)  \ 02H)  ; 

/X  SET  DHTSFLAG  BIT  1 */ 

D ISK®  < A®  D I SK  N 4011); 

/*  SET  TCT3DM  BIT  6 */ 

ERROR®  ( A® O)  ; 

/*  CLEAR  ERROR  X/ 

END; 

END; 

END; 

/*  MODIFY  DHTSFLAG  */ 

DE= . DHTSFLAG;  A® DISK  1FH;  CALL  [INDEX]; 

M(HL)  = (A=M(HL)  \\  02ID  ; /*  SET  DHTSFLAG  BIT  1 

x*  MODIFY  TCT3DM 

DE=  . TCTSDTf;  A® TASK;  CALL  [ INDF.XBI  : 

DE=nL;  A® DRIVE;  CALL  [INDEX]; 

B=H(  HL)  ; 

TK  HL)  = ( A®  DISK  s BOH);  /»  SET  TCT'DM  BIT  7 »/ 

/*  RESET  OLD  DISK'S  IN  USE  BIT  «/ 

IF  ( A® B 40H)  ZERO  CALL  CLEARSFLAG; 

/X  DISPLAY  STATUS  TISG  */ 

B=  ( A®  DR  I VE)  ; C=(A=DISK  1FH); 

IF  (A=DISK  4011)  T ZERO  THEN  A=72II  ELSE  A®  • '; 

C ALL  I STATUS3TISG1  ; 

END  ATTACH: 

LOCIN:  PROCEDURE: 

sc****:#::#:**:#:**/ 

/X  THIS  SYSTEM  CALL  NOT  I F I ES  TITS  THAT  THE  REQUESTING  X/ 
/*  TERMINAL  IS  NOW  ACTIVE,  AND  SIMULATES  TIIE  PHYSICAL  */ 
/*  COLD-START  BOOTSTRAP  OPERATION.  THE  BOOTSTRAP  LOAD  */ 
/*  TAKES  PLACE  FROM  VIRTUAL  DRIVE  A.  THE  VIRTUAL  DISK  xy 


/X  AIT  ACHED  TO  THIS  DRIVE  MAY  BE  SPECIFIED  IN  TIIE  */ 

/*  PARAMETER  LIST,  OR  DISKO  WILL  BE  ASSUMMED  AS  THE  */ 
/*  DEFAULT.  */ 

ARGUMENTS : 

/X  (I)  FID  =2  */ 

/X  (2)  PARM  = BASE  ADDRESS  OF  PARAMETER  LIST  */ 

s*  BYTE  o:  DISK  NUMDER  (0-31)  xs 

/*  BYTES  1-4:  PROTECTION  KEY  (0-4  CHARS)  X/ 

/X  VALUE:  ERROR  CODE  X/ 


/XXXXXX.XlXX.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'X.XXXXX/ 

/*  WRITE  MINI-DISK  BUFFER  IF  NECESSARY  X/ 

CALL  WRITE8BUF: 

IF  (A® ERROR  \ A)  IZERO  P.ETURN; 

/X  RE- INITIALIZE  TCT  */ 

CALL  CLEARSDM; 

DE=  . TCT3S IZF, ; A® TASK;  CALL  I INDEX]  ; 

M(  HL)  =32 ; /X  SIZE  = 16K  X/ 

IIL®  BC+(  DE=  . TCTOSTATUS)  ; 

M(HL)=1;  /*  SET  BIT  0 X/ 

/X  PROCESS  DISK  PARAMETER  X/ 

IF  ( HL®  PARTI;  A®  M<  HL)  ; A:  : OFFH)  IZERO  THEN 
DO;  /*  DISK  SPECIFIED  */ 

EC  = 3;  DE=HL;  TiL®  . PI.  IST(  I ) ; 
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CALL  C MOVBUF]  ; PARM=  ( HL=  . PL  1ST)  ; 
CALL  ATTACH: 

IF  (A=  ERROR  \ A)  IZERO  RETURN; 

END 

ELSE  /*  DISPLAY  DEFAULT  STATUS  MSG  */ 
DO; 

A=72H;  BC=0; 

CALL  [ STATUSSMSG]  ; 

END; 

/*  DISPLAY  SIZE  HSC  */ 

A=16;  CALL  l S IZE3MSGI ; 

END  LOGIN; 


PROTECT:  PROCEDURE; 

/**St*^c**5':S:*^*a:^:S;»:S:**»:*SS;*:,!;»:^:S:^:J:*Sc****>ic***^:W**S**M:****/ 

/*  THIS  SYSTEM  CALL  ADDS  THE  READ/WRITE  PROTECTION  */ 
/*  ATTRIBUTE  TO  A SPECIFIED  VIRTUAL  DISK  FILE.  */ 


/*  ARGUMENTS : */ 

/*  ( 1 ) F I D = 3 */ 

/"*  (2)  PARTI  = BASE  jVDDPESS  OF  PARAMETER  LIST 

/'*  BYTE  0:  DISK  NUMBER  (0-31)  */ 

/*  BYTES  1-4:  PROTECTION  KEY  (0-4  CHARS)  */ 

/*  VALUE:  ERROR  CODE  */ 


NOP; 

END  PROTECT; 


QUIT:  PROCEDURE; 

/X  THIS  SYSTEM  CALL  NOTIFIES  MTS  THAT  THE  REQUESTING  X/ 


/»  TERMINAL  IS  NO  LONGER  ACTIVE.  */ 
/*  ARGUMENTS : */ 
/*  ( 1)  FID  = 4 */ 
/*  (2)  PARM  = NONE  */ 
/*  VALUE:  NONE  */ 


/*  WRITE  MINI-DISK  BUFFER  IF  NECESSARY  */ 

CALL  VRITESBUF ; 

IF  ( A- ERROR  \ A)  IZERO  THEN 

DO;  £=d  HAJWWAHE3ERR0R] ; CALL  [ MTSSMSG) ; END; 
/*  CLEAR  STATUS  LINE  ■</ 

A=TASK;  CALL  C CLEARSSTATUSSL INEI ; 

/*  CLEAR  TCT  */ 

CALL  CLEARSDM; 

DE= .TCTSSIZE;  A=TASKs  CALL  C INDEX] ; 

MOIL)  "32;  /'*  SIZE  = 16K  *■' 

HL=  BC-*- ( DE=  . TCTSSTATUS)  ; 

M(  HL)  * 0 ; /*  RESET  STATUS  BYTE  *-/ 

GOTO  [MONITOR]; 

END  QUIT; 


BUMP:  PROCEDURE; 

GALL  WRITF.SB'JF ; 

IF  (A= ERROR  S A)  IZERO  THEN 

DO;  E=  I HARDW'ARESERROR]  ; CALL  [MTSSMSG];  END; 
A=TASK;  CALL  [ CLEARSSTATUSSL I NE] ; 

CALL  CLEARSDM; 

DE= .TCTSSIZE;  A=TASK;  CALL  [INDEX]; 

M( HL) =32 ; 

HL=  BC-K  DE= . TCTSSTATUS)  ; 

M(  ITL ) = 0 ; 

END  BUMP; 

RESTRICT:  PROCEDURE; 

/*  THIS  SYSTEM  CALL  ADDS  THE  READ  RESTRICTION  ATTRI-  */ 
/«  BUTE  TO  A SPECIFIED  PROTECTED  VIRTUAL  DISK  FILE.  */ 
/*  ARGUMENTS : *' 

/x  (DFID  *3  */ 

/*  (2)  PARM  = BASE  ADDRESS  OF  PARAMETER  LIST  */ 

/*  BYTE  0:  DISK  NUMBER  (0-31)  *z 

/*  BYTES  1-4:  PROTECTION  KEY  (0-4  CHARS)  */ 
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/*  VALUE:  ERROR  CODE  */ 

/'*****:):*:|c*c*:*-.t:**:S******:<'******=it:>:*****:it:.’:**:.’:****:l=****St*St*t/ 

NOP; 

END  RESTRICT; 

SIZE:  PROCEDURE; 

/*******  j*****************:*****************************/ 
/*  THIS  SYSTEM  CALL  SETS  THE  SIZE  OF  THE  USER'S  SWAP  */ 


/*  I MACE . */ 
/*  ARGUMENTS:  */ 
/*  (1)  FID  • 6 */ 
/*  (2)  PARM  = REQUESTED  SIZE  IN  KILOBYTES  */ 
/*  VALUE:  ERROR  CODE  */ 


/*  COMPARE  REQUESTED  SIZE  WITH  MAX  SIZE  */ 

IF  (A3PARM(0>;  A::49)  ICY  THEN 

/*  OUT  OF  BOUNDS  - ERROR  7 */ 

DO;  ERROR1  ( A3  7 ) ; RETURN;  END; 

/*  COMPARE  REQUESTED  SI7.E  WITH  SWAP  FILE  SIZE  */ 

DE= . TCTSBOE;  A3 TASK;  CALL  [ INDEX2]  ; 

CALL  [GET!;  B=0;  C= ( A=<  < PARM( 0) ) ; 

IIL=BC+DE;  STACK3 HL ; /*  SAVE  SUM  */ 

DE= . TCTSEOE;  A= TASK;  CALL  [ INDEX2] ; 

CALL  [GET!;  BC=BC+1; 

DE= STACK;  /*  RESTORE  SUM  */ 

A=  C-E ; A= B — D; 

IF  MINUS  THEN 

/*  OUT  OF  BOUNDS  - ERROR  7 */ 

DO;  ERROR3  (A=7);  RETURN;  END; 

/*  DISPLAY  SIZE  MSG  */ 

A=  PARIK  0) ; CALL  [ S IZESMSGI : 

/*  UPDATE  TCT  */ 

DE= .TCT3SIZE;  A=TASK;  CALL  [ INDEX] ; 

M( HL) 3 ( A=<  < PARM(  0) ) ; 

END  SIZE; 

UNPROTECT:  PROCEDURE; 

/****************************:*********:******:*:*********/' 
/*  THIS  SYSTEM  CALL  DELETES  THE  READ  RESTRICTION  AND  */ 
/at  READ/WRITE  PROTECTION  ATTRIBUTES  FROM  A SPECIFIED  */ 


/*  VIRTUAL  DISK  FILE.  */ 
/*  ARGUMENTS : */ 
/*  ( 1 ) F ID  3 7 */ 
/*  (2)  PARM  3 BASE  ADDRESS  OF  PARAMETER  LIST  */ 
/*  BYTE  0:  DISK  NUMBER  (0-31)  */ 
/*  BYTES  1-4=  PROTECTION  KEY  (0-4  CHARS)  */ 
/«  VALUE:  ERROR  CODE  */ 


/at**********:************:*:********:****************:):*:***/ 

NOP: 

END  UNPROTECT; 


EOF 

y*-x*xxxxx***x***x*v**xx**x**x*****x***x*****xx***xxx**x/ 
/*****************«*  SERVICE  CALLS  at»*****^**:s:*********/ 
/***:**:*:**.  a:**:*  »*;**:*  a:**:  **:•!:*:**:*  a:/ 


/##*****:.<*****  INTERMODULE  LINKAGE  MACROS  ************/ 

[ I NT  II2B  S2B]  [ M2B:  =O6O0H]  [S2B:=2200n] 

[MACRO  INDEX  ’[HEX  M2B  + 3H] • ] 

[ MACRO  INDEX2  * ( HEX  M23  + ODH] ’ ] 

[MACRO  INDEX8  ’[HEX  M2B  + 24H] ’ ] 

[ MACRO  GET  ’ [ HEX  M2B  + 38H] ’ ] 

[ MACRO  MOVBUF  ’ [ HEX  M2B  + 4 1 H]  ’ ] 

[ MACRO  MINISDISK  ’[HEX  M2B  + 34H] ’ ] 

/•I*;!::!:*!********!':**  GENERAL  PURPOSE  MACROS  at**************,' 

C MACRO  READ  ’ 1 ’ ] 

[MACRO  WRITE  ’2’ ] 
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READSUUF:  PROCEDURE; 

/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/ 
/x  THIS  PROCEDURE  READS  A SPECIFIED  MINI-DISK  SECTOR  */ 


sx  INTO  MDDUF  AND  UPDATES  MDSAD.  */ 
/X  INPUT:  DC  - MINI-DISK  SECTOR  NUMBER  */ 
/*  OUTPUT:  ERROR  - ERROR  CODE  */ 
/x  CALLED  BY:  MAP  X/ 


/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/ 

DE= . MDBUF ; L= C READ!  ; CALL  [ MIN ISDISK]  ; 

IF  (A: : 0)  IZERO  THEN 

/x  HARDWARE  ERROR  - ERROR  8 */ 

DO;  ERROR*  ( A*  8)  ; RETURN;  END; 

MDSAD* (HL=BC) ; 

END  READ3EUF; 

WRITESBUF:  PROCEDURE; 

/********:K:****:R**#*.*.:*:*****:t:***.-t:*:t:*********:f:*:tc:*******:l:**/ 

/x  THIS  PROCEDURE  CHECKS  THE  MODIFICATION  BIT  IN  */ 

/x  VDCCDRIVE  TO  DETERMINE  IF  THE  CONTENTS  OF  MDBUF  */ 

/*  HAVE  BEEN  ALTERED.  IF  SO,  THE  BUFFER  IS  WHITTEN  TO  */ 

sx  THE  MINI-DISK  AND  THE  MOD  BIT  IS  RESET.  X/ 

/X  CALLED  BY:  QUIT,  MAP , LOGIN  x/ 

/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/ 
IF  ( A=< VDC3DRIVE)  TCY  RETURN; 

BC= ( HL= MDSAD) ; DE=. MDBUF; 

L=  I WR I TE I ; CALL  IMINISDISKI; 

IF  ( A : : 0 ) IZERO  THEN 

/X  ILVRDWARE  ERROR  - ERROR  8 */ 

DO;  ERROR*  (. A= O)  ; RETURN;  END; 

VDCSDR I VE=  ( A*  VDCSDR I VE  7FH)  ; 

END  WRITESBUF: 

MAP:  PROCEDURE; 

/*  THIS  PROCEDURE  CALCULATES  THE  RELATIVE  OFFSET  OF  A */ 
/x  SPECIFIED  VIRTUAL  FLOPPY  DISK  SECTOR  IN  THE  MINI-  X/ 
/x  DISK  FILE  AND  THE  BASE  ADDRESS  OF  THAT  SECTOR  IN  */ 
SX  THE  MINI-DISK  BUFFER  AFTER  THE  FILE  IS  READ.  THEN  */ 
/X  IT  CALCULATES  THE  ACTUAL  MINI-DISK  SECTOR  NUMBER  X/ 
/x  CONTAINING  THE  ADDRESSED  FLOPPY  DISK  SECTOR,  AND  */ 
/x  COMPARES  IT  WITH  THE  CURRENT  CONTENTS  OF  MDBUF.  IF  x/ 


/x  THE  TWO  ARE  NOT  EQUAL,  THE  OLD  BUFFER  IS  WHITTEN  */ 
/*  TO  THE  MINI-DISK  AND  THE  NEWLY  CALCULATED  SECTOR  x/ 
/x  NUMBER  READ  IN  TO  REFILL  THE  BUFFER.  A COMPARISON  */ 
/X  IS  ALSO  MADE  BETWEEN  THE  CALCULATED  MIN  I -DISK  XS 

/X  SECTOR  NUMBER  AND  THE  FILE'S  EOE  VALUE  TO  ENSURE  X/ 
/x  THAT  THE  SPECIFIED  VIRTUAL  DiSIC  SECTOR  ADDRESS  IS  X/ 
/x  WITHIN  THE  BOUNDS  OF  THE  FILE.  x/ 

/x  INPUT:  VDC8TRACK  - FLOPPY  DISK  TRACK  NUMBER  x/ 

/x  VDC8SECT0R  - FLOPPY  DISK  SECTOR  NUMBER 

/*  OUTPUT:  BC  = 128  = FLOPPY  DISK  SECTOR  SIZE  x/ 

/■ x HL  * BASE  ADDBESS  OF  FLOPPY  DISK  SECTOR  xs 

/x  IN  BUFFER  x/ 

/x  CALLED  BY:  READSELOPPY,  WRITESFLOPPY  X/ 


/ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX / 
DECLARE  BUFAD  DATA  (0,0); 

DECLARE  SECNR  DATA  (0,0); 

/X  MULTIPLY  TRACK  NUMBER  BY  26  */ 

D= ( A=  VDCSTRACK)  : 

E= ( A*  VDCSSECTOR)  ; 

B=0;  C=26;  H=8: 

C=( A=>C) ; 

REPEAT; 

IF  CY  THEN  A= B+D: 

CY=0;  B= ( A=  > A) ; 

C=( A=>C) ; 

UNTIL  (H=H-1)  ZERO;  /X  BC  = 26  * TRACK  */ 

/x  ADD  SECTOR  NUMBER  TO  26  x TRACK  */ 

C- ( A=C+E) ; B= ( A* B++0) ; 


183 


r 


/*  BC  » 26  * TRACK  + SECTOR  */- 
/*  DIVIDE  26  * TRACK  + SECTOR  BY  4 */ 

DE=0; 

CY=0;  B=(A=>B>;  C=(A=>C);  E=CA=>E); 

CY=0;  B=(A=>B);  C=(A=>C);  D=(A=<D); 

/*  BC  BC  / 4 */ 

/*  DE  = RELATIVE  BUFFER  ADDRESS  */ 
BUFAD=(  IIL=DE) ; /*  SaVE  RELATIVE  BUFFER  ADDRESS  */ 

S*  CALCULATE  AND  SAVE  NEW  MINI-DISK  SECTOR  NR 
SECNR=  ( IIL=  VDC9BOE  + BC)  ; 

/*  COMPARE  NEW  SECTOR  NR  WITH  VDCSEOF.  */ 

A=VDCSEOE< 1>-L;  A=VBCSE0E(0) — Hi 
IF  MINUS  THEN 

/*  OUT  OF  BOUNDS  - ERROR  7 */ 

DO;  ERROR=(  A=7) ; RETURN;  END; 

/*  COMPARE  NEW  SECTOR  NR  WITH  MDSAD  */ 

IF  ( A=  MDSADI  0) ; A::H)  ’ZERO  THEN 
CY-0 

ELSE  IF  ( A= MDSADC 1 ) ; A::L)  TZERO  THEN 
CY=0 

ELSE  CY=  1 ; 

/*  WRITE  OLD  SECTOR  AND  READ  NEW  IF  NECESSARY  */ 

IF  ICY  THEN 

DO;  NOT  EQUAL 

CALL  WRITESEUF ; 

IF  (A= ERROR  \ A)  I ZERO  RETURN; 

BC= ( HL=SECNR) ; CALL  READSBUF ; 

IF  < A=  ERROR  N A)  IZERO  RETURN; 

END; 

/*  SET  UP  REGISTERS  FOR  RETURN  */ 

BC- 123;  DE=  ( HL= BUFAD) ; 

END  MAP; 

S##****#;!:**#*** SERVICE  ROUTINES 
WRITESPRINTER:  PROCEDURE; 

/*****  JR*****************:, Sx**x************:x**:R*:**;R:R:*****/ 


/*  THIS  SERVICE  CALL  IS  CALLED  TO  V;RITE  A SINGLE  *■/ 
/*  CHARACTER  TO  THE  SERIAL  PRINTER.  */■ 
/*  ARGUMENTS : */ 
/*  (1)  FID  = 11  */ 
✓*  ( 2)  PARM  = ASCII  CHARACTER 

/*  VALUE:  ERROR  CODE  */ 


/****X**:*:f:*X***X***:!:******:fc*:KX**X*X:<:**:*:**X********X:S*:*:*/'' 

NOP; 

END  WRITESPRINTER; 


SELECT3DRIVE:  PROCEDURE; 

/XXXXXX******  X*XXX*X*XX:;:X*:::X**:R*#**:RX*:,,:******S******:RS:*/' 

/*  THIS  SERVICE  CALL  SELECTS  THE  VIRTUAL  FLOPPY  DISK  */ 


/*  DRIVE  TO  BE  USED  FOR  SUBSEQUENT  FLOPPY  DISK  */ 
/*  ACCESSES.  */ 
/*  ARGUMENTS : */ 
/*  (1)  F ID  = 12  */ 
/*■  (2)  PARM  * DRIVE  NUMBER  (0-7)  *s 
/*  VALUE:  ERROR  CODE  */ 


✓'jR*****:******#*  ****:M:**#*****."S:‘:***:f;:f:**:fc*******iM:*******/ 

DRIVE1  ( A=PARM(  1) ) ; 

/*  VALIDATE  DRIVE;  NUMBER 
IF  (A: : 8)  ICY  THEN 

/*  DRIVE  NR  > 7 - ERROR  6 */ 

DO;  ERROR1  ( A=6)  ; RETURN;  END; 

/*  VALIDATE  THAT  DRIVE  IN  USE  */ 

DE“ . TCT8DM;  A* TASK;  CALL  CINDEX8I; 

DE=HL;  A= DRIVE;  CALL  I INDEX]  ; 

IF  ( A=<  M(  HL)  ) ICY  THEN 

✓ * DRIVE  NOT  AVAIL  - ERROR  10  */ 

DO;  ERROR1  ( A= 10)  ; RETURN;  END; 

UPDATE  VDC  BLOCK  */ 

DISK=(A=M(HL)  IFH)  ; 

IF  ( A=M(  HI.)  4011)  IZERO  THEN  /*  READ  ONLY  */ 

DRIVE=(  A= DRIVE  \ 40n) ; /*  SET  BIT  6 */ 
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DE= . DMT8B0E;  A=DISK;  CALL  I INDEX23 ; 

CALL  CCETI;  VDCSBOE=( HL=BC) ; 

DE= . DMT3EOE;  A=DISK;  CALL  [ INDEX2I ; 

CALL  [ GET1 ; VDC$EOE=  C HL=BC) ; 

VDC8DRI VE= ( A=  DRIVE) ! 

END  SELF.CT3DRIVE; 

SETSDMA:  PROCEDURE; 

/:f.  X *:K  S:**  XHc#*#:/;?.*#**?!:*:*#******#*******#*******/' 

/*  THIS  SERVICE.  CALL  SETS  THE  ADDRESS  OF  THE  120  DYTE 
/*  DMA  BUFFER  TO  BE  USED  IN  SUBSEQUENT  VIRTUAL  FLOPPY 


/»  D TSK  ACCESSES.  */ 
/*  ARGUMENTS : */ 
/*  ( 1)  FID  = 13 

/*  (2)  PARM  = DMA  ADDRESS  */ 
/*  VALUE:  ERROR  CODE 


/*****:**:*:|:******'.;<*****:*:fc**#*:l::£-'S*:.;:S<:t:*:****:#:*:.‘:*********:.l:.<:*/ 

A=  PARM(  1 ) -0 ; A=PARM(  O) — 40H; 

IF  MINUS  THEN 

/*  OUT  OF  BOUNDS  - ERROR  7 */ 

DO;  ERROR-  ( A=7) ; RETURN;  END: 

VDCSDMA= ( HL= PARM) ; 

END  SET3DMA; 

SET3TRACK:  PROCEDURE; 

s*  TOIS  SERVICE  CALL  SETS  THE  TRACK  NUMBER  TO  BE  USED 


/*  III  SUBSEQUENT  VIRTUAL  FLOPPY  DISK  ACCESSES.  *' 

/*  ARGUMENTS : */ 

/*■  ( 1)  FID  = 14  */ 

/*  (2)  PARM  = TRACK  NUMBER 

/*  VALUE:  NONE 


/'iB:*;*:*:****.:*:*:!*:**:**::**:*:^:*:*:*;*::;*:*:**::*:!:*!*::'::#*'*::**:*:*:*:*:*:;:  Be***  IK**:*  Jr.*/' 

VBCSTRACK*  ( A= PARMI  I ) ) : 

END  SETJTRACK; 


SET5SECT0R:  PROCEDURE; 

/ :S  * :B  :(c  * :K  :£ S :«  :B  :B  :B  v:  :*  3:  * :R W :S  :R  * * * * :;: » :ft  :B  * :«  *«:(::!::,':******/ 


/*  THIS  SERVICE  CALL  SETS  THE  SECTOR  NUMBER  TO  BE  */ 
/*  USED  IN  SUBSEQUENT  VIRTUAL  FLOPPY  DISK  ACCESSES.  */ 
/*  ARGUMENTS : */ 
/■*  C 1)  FID  = 13  */■ 
/*  (2)  PARM  = SECTOR  NUMBER  (1-26)  */ 
/*  VALUE:  ERROR  CODE  */ 


A=  PARIK  1 ) : 

IF  (A:: 27)  ICY  \ (A::0)  ZERO  THEN 
OUT  OF  BOUNDS  - ERROR  7 */ 
DO;  ERROR= (A= 7);  RETURN;  END; 
VDCSSECTORs  A ; 

END  SET® SECTOR; 

READSFL  "'PPY : PROCEDURE; 


/*  THIS  SERICE  CALL  SIMULATES  READING  FROM  A FLOPPY  */ 
/%  DISK.  THE  VIRTUAL  DISK  SECTOR  AND  TRACK  SPECIFIED  */ 
/*  IN  THE  VDC  BLOCK  IS  READ  FROM  THE  SPECIFIED  */ 
/*  VIRTUAL  DRIVE  INTO  A 128  BYTE  BUFFER  IN  THE  USER’S  */ 
S*  SWAP  AREA. 

ARGUMENTS:  */ 
✓*  ( 1)  FID  = 16  */ 
/*■  (2)  PARM  = NONE  */ 
/'%  DRIVE,  SECTOR.  TRACK.  AND  DMA  ADDRESS  MUST  */ 
/*  HAVE  BEEN  PREVIOUSLY  SET  BY  CALLS  TO  THE  */ 
/*  APPROPRIATE  PROCEDURES.  */ 
S-*  VALUE:  F.RROR  CODE  */- 


CALL  MAP; 

IF  (A= ERROR  S A)  ’ZERO  RETURN; 

DE=  HL ; 11L=  VDC  CDMA;  CALL  f M0VBUF1  ; 
END  READSFLOPPY; 
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WRITF.9FL0PPY:  PROCEDURE; 

/*****************  ****&*******:*:************************/' 


/*-.  THIS  SERVICE  CALL  SIMULATES  WRIT  I IIG  TO  A FLOPPY  */ 
/*  DISK.  A 128  BYTE  BUFFER  IN  THE  USER  SWAP  AREA  IS  */ 
/*  WRITTEN  TO  THE  VIRTUAL  TRACK.  SECTOR,  AND  DRIVE  */ 
/*  SPECIFIED  IN  THE  VDC  BLOCK.  */ 
/*  ARGUMENTS:  */ 
/*  < 1)  FID  = 17  */ 
s*  (2)  PARTI  • NONE 

/*  DRIVE,  SECTOR,  TRACK,  AND  DMA  ADDRESS  MUST  */ 
/*  HAVE  BEEN  PREVIOUSLY  SPECIFIED  BY  CALLS  TO  */ 
/*  THE  APPROPRIATE  PROCEDURES.  */ 
/*  VALUE:  ERROR  CODE  */ 


CALL  MAP; 

IF  (A= ERROR  \ A)  f ZERO  RETURN; 

STACK=  HL ; DE=  ( HL=  VDC3DMA)  ; 

HL= STACK:  CALL  [ MOVBUF1 ; 

VDCSDRI VE=  ( A=  VDCSDRI VE  \ 80H)  ; /*  SET  BIT  7 

END  WRITE3FL0PPY; 

EOF 


i 
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/****************************************************/ 
/************  TERMINAL  INTERFACE  MODULE  ***********/ 

/yc**:C*:<:*:t:*;l;:j:S:****:S*******************************:r:**:|:/ 


/* 


*/ 


/*  TERMINAL  INTERFACE  MODULE  PROVIDES  THE  MTS  */ 


/*  INTERFACE  WITH  THE  FOUR  DISPLAY  TERMINALS  */ 
/*  ATTACHED  TO  THE  SYCOR  440  SYSTEM.  THE  MODULE  IS  */ 
/*  SEPARATED  INTO  FIVE  BASIC  SUBMODULES.  EACH  */ 
/*  SUBMODULE  CONTAINS  THE  MACHOS  NECESSARY  FOR  */ 
/*  LINKING  W I TU I N THE  TERMINAL  MODULE  AND  FOR  */ 
/*  EXTERNAL  MTS  LINKAGE.  */ 
sx  */ 


/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/» 

/* 

/* 

/* 

/* 

/* 

/■■< 

/» 

/* 

/* 

/* 

/* 

/% 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/•* 


(1)  DATA  DECLARATIONS  */ 

THIS  SUBMODULE  PROVIDES  ALL  DECLARATIONS  OF  */ 

THE  DATA  STRUCTURES  UTILIZED  BY  THE  TERMINAL*/ 
MODULE.  */ 

(2)  UTILITY  PROCEDURES  */ 

THIS  SUBMODULE  CONTAINS  THE  BASIC  UTILITY  */ 

PROCEDURES  WHICH  PROVIDE  COMMON  REGISTER  */ 

MANIPULATION  AND  PROCESSING  REQUIRED  BY  */ 

MANY  PROCEDURES  THROUGHOUT  THE  REMAINDER  */ 

OF  THE  TERMINAL  INTERFACE  MODULE.  */ 

* COMP ARES PTRS  * GETS  INDEX  */ 

* GETSVALUE  * STORES  VALUE  */ 

* C0NVF.RT0NUMBR3T03ASC  I I */ 

* MOVE’S  BYTES  * SWAFSCURSOR  */ 

(3)  TERMINAL  INTERFACE  PRIMITIVES  */ 

THIS  SUBMODULE  CONTAINS  THE  PROCEDURES  WHICH*/ 
PROVIDE  THE  BASIC  TERMINAL  INTERFACE  */ 

FUNCTIONS.  */ 

* BLANKS D I SPLAY  * GETSD I SPLAYS ADDR  */ 

* CHECKS CURS OH  * GETSTERMSSTATUS  */ 

* SCROLLED ISPLAY  * SENDOEEEP  */ 

* SENDSCLICK  * UPDATESCURSOR  */ 

* GET3STATUSS ADDR  */ 

(4)  KEY  PROCESSING  PROCEDURES  */ 


THIS  SUBMODULE  CONTAINS  THE  PROCEDURES  WHICH*/ 
PROVIDE  THE  BASIC  TERMINAL  INPUT  PROCESSING.*/ 


THEY  ARE  CALLED  TO  PROCESS  EACH  KEY  ENTERED  */ 
AT  A TERMINAL.  THEIR  FUNCTIONS  INCLUDE:  */ 

CHECKING  FOR  .AND  CONVERTING  LOWER  TO  UPPER  */ 
CASE  LETTERS  IF  REQUIRED:  CHECKING  FOR  ANY  */ 
KEY  COMMANDS  (WHICH  INCLUDES  ALL  LINE  */ 

EDITING):  AND  IF  NOT  A KEY  COMMAND,  */ 

DISPLAYING  THE  INPUT  CHAR  AT  THE  TERMINAL.  */ 

* KEYSCOMMAND  * TERMS  I NPUTSCNTL  */ 

(5)  TERMINAL  INTERFACE  SYSTEM  FUNCTIONS  */ 

THIS  SUBMODULE  CONTAINS  THE  PROCEDURES  WHICH*/ 
PROVIDE  THE  PROCESSING  REQUIRED  TO  INTERFACE*/ 
THE  TERMINAL  WITH  THE  REST  OF  THE  MTS  */ 

MODULES.  IT  PROVIDES  READ  INC  AND  WRITING  */ 

OF  CHARACTERS  FROM/TO  THE  TERMINALS;  */ 

TERMINAL  STATUS  INFORMATION  (E.G.  WHETHER  */ 
THERE’S  INPUT  AVAILABLE  OR  NOT);  AND  DISPLAY*/ 
OF  STATUS  AND  MTS  MESSAGES  ON  THE  TERMINAL  */ 
STATUS  LINE.  */ 

* BL I NKSCURSORS  * CLEARSSTATUSSLINE  */ 

* TERM I N ALSSTATUS  * RE ADSTERM I NAL  */ 

* WR I TESTERM INAL  * STATUS8MSG  */ 

* MTS3MSG  * SIZE5MSG  */ 


/****************************************************/ 
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/****************************************************/ 
yxxxxxxxxxxxx  TERMINAL  DISPLAY  DESICN  *************/ 


/*  */ 

/X  X/ 

/■*  GENERAL  FORMAT  OF  EACH  TERMINAL  DISPLAY  */ 

/*  */ 

/X  */ 

/X  */ 

/x  10  STATUS  LINE  631  */ 

/*  */ 

/*  */ 

/*  10  D 631  */ 

/*  */ 

/X  164  I 1271  */ 

/%  */ 

/*  1128  B S 1911  */ 

/*  */ 

/*  1192  U P 2551  */ 

/*  */ 

/*  1256  F L 3191  X/ 

/x  */ 

/X  1 320  F A 383 1 */ 

/x  */ 

/:K  1 384  E Y 447  I X/ 

/X  X/ 

/*  1448  R 51  % I */ 

/*  */ 

/X  */ 

/X  X/ 

/*  STATUS  LINE  */ 

/■*.  w/ 

/X  10  VFD  39  140  MS  47  143  MSG  63 1 */ 

/*  x/ 

/*  WHERE  */ 

/*  VFD  - VIRTUAL  FLOPPY  DISK  STATUS  DISPLAY;  */ 

/*  CONTAINS  THE  INFORMATION  .ASSOCIATED  */ 

/X  WITH  THE  CURRENT  TERMINAL  USER’S  */ 

/*  VIRTUAL  FLOPPY  DISK  DRIVE  AND  DISK  */ 

/x  NUMBER  ASSIGNMENTS.  (SEE  STATUSSMSG  */ 

/*  PROC  FOR  DETAILS)  X/ 

/x  MS  - DISPLAY  OF  THE  MEMORY  SIZE  THE  USER  */ 

/x  IIAS  REQUESTED.  (SEE  S1ZF.SMSG  PROC)  X/ 

/X  MSC  - DISPLAY  AREA  FOR  MTS  MESSAGES  WHICH  x/ 

/X  ARE  DISPLAYED  IN  RESPONSE  TO  A X/ 

/ X SYSTEM  OR  SERVICE  CALL  TO  MTS.  */ 

/x  (SEE  MTS3MSG  PROC)  x/ 

/X  X/ 

/x  x/ 

/X  DISPLAY  BUFFER  x/ 

/x  */ 


/■"*  */ 

/x  THE  DISPLAY  BUFFER  IS  VIEWED  AS  A SINGLE  X / 
/x  BUFFER  FROM  0 TO  512  BYTES  IN  LENGTH.  THERE  ARE  x/ 
/x  FOUR  DISPLAY  BUFFER  POINTERS  WHICH  PROVIDE  THE  x/ 
/ x CONTROL  OF  INPUT  FROM  AND  OUTPUT  TO  THE  TERMINAL  X/ 
/X  DISPLAY.  THESE  POINTERS  ARE:  CURRENTSLINE;  X/ 
/x  CURSOR;  NEHTSCHAR;  AND  ENDSIBUFF.  x/ 
sx  EACH  POINTER  UTILIZES  TWO  BYTES  OF  STORAGE  TO  */ 
/x  ACCOMMODATE  A RANGE  IN  VALUE  FROM  0 TO  512.  */ 
/*  IN  ADDITION  TO  THESE  POINTERS,  THERE  IS  A x/ 
/x  TERMINAL  STATUS  BYTE,  CALLED  TERMSSTATUS,  X/ 
/x  ASSOCIATED  WITH  EACH  TERMINAL.  IT  IS  SET  TO  */ 
/*  ONE  OF  THREE  VALUES:  INPUTSWA ITING;  X/ 
/x  MTSSCMD® READY;  IBUFFSEMPTY.  THESE  /ARE  THE  X/ 
/*  PRIMARY  DATA  STRUCTURES  PROVIDING  TERMINAL  I/O  */ 
/*  CONTROL.  */ 
/X  X/ 
/x  THE  PRIMARY  SYCOR  HARDWARE  CHARACTERISTIC  WHICH  */ 
/x  AFFECTED  THE  MTS  TERMINAL  INTERFACE  WAS  THE  */ 
/x  RELATIVELY  SLOW  MINI-DISK  ACCESS  TINES.  THIS  HAS*/ 
/*  A MAJOR  IMPACT  WHEN  TRYING  TO  DESIGN  AN  */ 
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/*  INTERACT I VE  TIMES HARED  SYSTEM.  INORDER  TO  */ 
/*  PROVIDE  REASONABLE  INTERACTIVE  RESPONSE  TIMES  */ 
/*  TO  USER  ACTIONS,  THE  TERMINAL  INTERFACE  */ 
/*  MODULE  PROVIDES  AI.L  LINE  EDITING  FEATURES  FOR  */ 
/*  THE  USER  PRIOR  TO  TRANSFER  I NG  ANY  DATA  TO  THE  */ 
/*  USER’S  PROGRAM.  (SEE  KEYSCOMMAND  PROC)  */ 
/*  TUE  TERMINAL  DISPLAY  DESIGN  UTILITZES  TWO  */ 
/*  SEPARATE  BUFFERS  TO  PROVIDE  THE  USER  WITH  THE  */ 
/*  CAPABILITY  OF  CONTINUING  TO  ENTER  DATA  PRIOR  */ 
/*  TO  THE  USER’S  PROGRAM  BEING  SWAPPED  IN  TO  */ 
/*  PROCESS  THE  PREVIOUS  INPUT  LINE.  */ 
/*  THE  FIRST  BUFFER  IS  CALLED  THE  ’CURRENT  LINE’  */ 
/*  AND  CONTAINS  THE  INPUT  DATA  WHICH  IS  CURRENTLY  */ 


/*  BEING  ENTERED  BY  THE  USER.  THE  CURRENT  LINE  CAN  */ 
/*  RANGE  FROM  O TO  512  BYTES  IN  LENGTH.  THIS  IS  THE*/ 
/*  DATA  THAT  IS  AFFECTED  BY  ANY  LINE  EDITING  COMMAND*/ 


/*  ENTERED  BY  THE  USER.  */ 

/*  THE  SECOND  BUFFER  IS  THE  INPUT  LINE  OR  BUFFER.  */ 
/*  THE  CURRENT  LINE  BECOMES  THE  INPUT  LINE  WHENEVER  */ 
/*  A CARRIAGE  RETURN  OR  ERROR  RESET  (MTS  COMMAN D */ 
/*  KEY)  IS  ENTERED.  THIS  ACTION  ALSO  ESTABLISHES  */ 
/*  A NEW  CURRENT  LINE.  THE  INPUT  LINE  CONTAINS  THE  */ 
/*  THE  DATA  WHICH  IS  TRANSFERRED  TO  THE  USER  PROGRAM*/ 
/*  WHEN  REQUESTED.  THUS  THERE  CAN  BE  AN  INPUT  LINE  */ 
/*  AND  A CURRENT  LINE  ESTABLISHED  AT  ONE  TIME.  */ 

/*  THE  CURRENT  CURSOR  POSITION  ALWAYS  SPECIFIES  */ 

/*  WHERE  THE  NEXT  CHARACTER  WILL  BE  ENTERED,  ON  */ 

/*  INPUT,  AND  WHERE  THE  NEXT  CHARACTER  WILL  BE  */ 

/*  DISPLAYED  DURING  OUTPUT.  */ 

/*  */ 

/*  THE  FOLLOWING  IS  AN  EXAMPLE  OF  POINTER  */ 

/*  MAN IPULATION  DURING  INPUT:  */ 

/*  INITIALIZATION  OR  CLEAR  SCREEN  CMD : */ 

/*  ALL  POINTERS  ARE  SET  TO  ZERO  AND  */ 

/*  TERMSSTATUS  = INPUT  BUFFER  EMPTY.  */ 

/*  USER  ENTERS  DATA  - "SAMPLE  INPUT  DATA":  */ 

/*  CURRENTSLINE  POINTS  TO  THE  STARTING  POSITION*/ 

/*  AND  CURSOR  ALWAYS  POINTS  TO  THE  NEXT  */ 

/*  POSITION  TO  FILL.  NOTE  THAT  AT  THIS  POINT  */ 

/*  ONLY  CURSOR  HAS  BEEN  MODIFIED.  FOR  THE  */ 

/*  INPUT  DATA  ABOVE  IT  WOULD  BE  POINTING  TO  */ 

/*  DISPLAY  BUFFER  POSITION  IT.  */ 

/*  USER  TERMINATES  CURRENT  LINE  (I.E.  ENTERS  CR  OR  */ 
/*£  MTS  $ CMD)  s Jfc/ 

/*  ENDS IBUFF  IS  SET  TO  CURRENT  CURSOR  POSITION.*/ 

/*  CURSOR  IS  SET  TO  LEFT  MOST  POSITION  OF  NEXT  */ 

/*  LINE  ON  DISPLAY.  */ 

/*  CURRENTSLINE  IS  SET  TO  NEW  CURSOR  POSITION.  */ 

/*  TERMSSTATUS  IS  SET  TO  INPUT  WAITING.  */ 

/*  */ 

/*  THE  RESULTING  POINTER  POSITIONS  ARE  SHOWN  FOR  THE*/ 
/»  SAMPLE  INPUT  DATA  AND  CR  CHARACTERS  ENTERED.  */ 

/*  (WHERE  * = CURRENT  CURSOR  POSITION)  */ 

/*  */ 

/*  NC  EIB  */ 

/*  */ 

/*  I SAMPLE  INPUT  DATA  I */ 

/*  */ 

/*  I * I */ 

/#  */ 

/*  CL  */ 

/*  */ 

/*  THE  SAMPLE  INPUT  DATA  IS  NOW  AVAILABLE  FOR  THE  */ 

/*  USER’S  PROGRAM  WHEN  IT’S  TIMF.SLICE  COMES  UP.  */ 

/*  THE  NEXTSCHAR  (NC)  POINTER  SPECIFIES  THE  NEXT  */ 

/*  CHARACTER  TO  BE  READ  AND  RETURNED  TO  THE  USER  */ 

/*  PROGRAM.  WHEN  NEXTSCHAR  = ENDS  I BUFF , A CARRIAGE  */ 
/*  RETURN  (CR)  IS  RETURNED  TO  THE  CALLING  USER  */ 

/*  PROGRAM.  */ 

/*  THERE  ARE  THREE  OCCASIONS  WHEN  THE  NEXTSCHAR  */ 

/*  POINTER  IS  RESET  EQUAL  TO  THE  CURRENTSLINE  */ 

/*  POINTER:  */ 
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p 

/* 

/* 

/* 

/* 

/* 


/*  TIIE  OUTPUT  OF  DATA  FROM  THE  USER’S  PROGRAM  TO  */ 
/*  THE  TERMINAL  RESULTS  IN  TIIE  FOLLOWING:  */ 

/*  (1)  THE  CHARACTER  IS  DISPLAYED  AT  THE  CURRENT 

/*  CURSOR  POSITION.  */ 

/*  (2)  THE  CURSOR  POSITION  IS  INCREMENTED.  */ 

/*  (3)  THE  CURRENT8LINE  AND  NEXT3CHAR  POINTERS  ARE  */ 

/*  SET  EQUAL  TO  THE  NEW  CURSOR  POSITION.  */ 

/*  (4)  THE  TERMINAL  STATUS  IS  SET  TO  EMPTY.  */ 

/*  */ 

*/ 

/*  ANOTHER  DESIGN  CONSIDERATION  WAS  THE  REQUIREMENT  */ 
/*  FOR  THE  TERMINAL  MODULE  TO  PROVIDE  A BLINKING 
/*  CURSOR  DISPLAY  AT  EACH  TERMINAL.  THIS  REQUIRED 
/*  SPECIAL  PROCESSING  TO  ENSURE  THAT  TIIE  CURSOR  */ 

/*  CHARACTER  (05FR)  DID  NOT  GET  LOST  DURING  THE  */ 

/*  CURSOR  UPDATE  AND  MANIPULATION  FUNCTIONS  */ 

ACCOMPLISHED  BY  TIIE  KEY  PROCESSING  AND  SYSTEM  *✓" 
/*  FUNCTION  SUBMODULES.  CIIECKOCURSOR  PROCC PRIMITIVE  */ 
/*  SUBMODULE)  PROVIDES  THIS  FUNCTION. 

/*  */ 

/*  */ 

/ ^ :s  : try. ^ * :::  :::  / 


si;:,*:**:*:  ******;*:«:  **:£*:**:»:***:*✓' 


Cl)  FOR  A CLEAR  SCREEN  COMMAND.  */ 

(2)  WHEN  READSTERMINAL  PROC  DETECTS  THAT  THE 

END  OF  THE  INPUT  BUFFER  HAS  BEEN  REACHED.  */" 

(3)  WHEN  WR I TESTER?! I N AL  PROC  OUTPUTS  CHARACTERS  */ 
TO  THE  TERMINAL  FROM  THE  USER'S  PROGRAM.  */ 

x./ 


/»****  TERMINAL  INTERFACE  DATA  DECLARATIONS  *#***»*/■ 


[MACRO  I BUFFSEMPTY  'O’  1 

[ MACRO  CURSORSCHAR  'oFH'I 

/'****************************************************/' 

/*********  TERMINAL  INTERFACE  DECLARATIONS  ********* 

/■*  ASCII  - CONTAINS  DATA  FOR  MATRIX  CODE  TO  ASCII*'" 

/*  CONVERS ION.  */ 

DECLARE  ASCII  DATA  ( 1EH, 1CH, 1BH, 5DH. 5BH, 29H, 28H, 7FH. 

26H, 3DH, 23H, 24H. 23H. 40H, 2 1H. 2AH. OAH. OCH, OBH, OAOH, 
ODH.50H.4FH.  13H,  55H,  39H,  54H.  52H,  4511,  3TH,  5 1 U,  49H, 

ODH. 9 , 3 1U. 9 , 22H, 3 AH, 4CH, ODH, 4 AH, 48H, 47H. 46  H , 44H. 53H, 
4 in. 4BH. 0FFH, 30H, 20H, 0A3H, 0A2H, 3FH, 3EH, 3CH. 4DH, 4 EIL 
42H,  3611.  43H.  38H, 3AH. OFFH. 

OFFH,  OFFH,  OFFn.  OFFII,  OFFH,  OFFH,  OFFH,  7FH,  OFFH,  OFFH. 
OFFH, 0A4U. OFFH, OFFH, OFFH, OFFn, OFFH, OFFH, OFFH, OAOH, 
ODH, OFFH. OFFH, 13H. OFFH, OFFH, OFFH, OFFH. OFFH, OFFH, 
OFFH, OFFH, OFFH. OFFH, OFFn, 09 , OFFH. OFFH,  OFFH,  ODH, 

OFFH, OFFH, OFFH , OFFH, OFFH, OFFH, OFFH, OFFH, OFFH, OFFH, 
20H, 0A3H, 0A2H, OFFH, OFFH, OFFH, OFFH, OFFH, OFFH, OFFH, 
0A1U, OFFH, OFFH, OFFH, 

OFFH, OFFH. OFFH , 5FH , OFFH . 7DH. 7BH, 7FH. OFFH. 7EH . 5CH , 
0A4H,  60H,  3EH,  7CII,  OFFH,  OFFII.  OFFII,  OFFH.  OAOH,  ODH, 
lOn.OFH. 13H. 15H. 19H, 14H, 12H.05, 17H, 11H.09.60H, 

5En,  7CH.  09  , OFFII.  OFFH.  OCH,  ODH,  OAH.  OB,  07. 06 . 04  , 

13H, 0 1 . OBH. OFFH. 7DH, 20H. 0A3H, 0A2H, OFFH, OFFH, OFFH, 
ODH.OF.L',92.  16H.03,  13H,  1AH.0FFH. 

39 H, 38n, 37H, 2DH. 2BH. 30H, 39H, 7FH, 37H. 36H, 35H, 34H. 

33  H ,32H,01H.08H,36)1, 33 H , 34H , OAOH, ODH. 70H, 6FH , I3H, 
73H,  7911.  74H.  7211.  6511.  77n,  7 1H.  69H,  33H.  32H.  3 1H,  09  . 

27H.  3BI1. 6CH,  0DI1 . 6 An,  68H,  67H.  6611.  64H.  73U.  6 1 H.  6BH, 
OFFH. 30H. 20H. 0A3H, 0A2H, 2FH. 2EH. 2CH. 6DH, 6 EH. 62H. 

76H, 63H, 78n, 7AH, OFFH) : 

/**•.(:*  ;K  ********  :R  ****:(::);:£  * * :K  & * * * » * *******  * ************/- 
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✓ * STATUS? BASE  - START  OF  STATUS  LINE  AT  EACH  TERM  */ 

✓ at  DISPLAYSBASE  - START  OF  DISPLAY  LINES  */ 

/*X'*.***%*-X-&**\t******X****X*%***.**X**X*-*-X.-»-***-*X*X.-*X.'X.-ie.%./ 

DECLARE  STATUS® BASE  DATA 

( 00H,  07H,  4011,  0911,  BOH,  OBU,  OCOH,  ODH) 
DECLARE  DISPLAYSBASE  DATA 

( 4011,  07H,  BOH , O9H.0COII,  OBH,  OOH.  OEH) 


✓ at  % * * * * K XX  tf  IS***:*:::::!!  * X*  # * :ft  * at. * at  :S  at  X tf  * at  Hi  X*  * * S T-  T-  a:  * at  at  at/ 

✓as  MTS3MESSAGE  - DATA  VECTOR  CONTAINING  ALL  THE  MTS  *✓ 
/*  MESSAGES  WHICH  MAY  BE  DISPLAYED  IN  */ 

✓at  THE  MTS  MSG  FIELD  OF  THE  STATUS  at/ 

✓ * LINE.  */ 

/*  S I ZES MESSAGE-  DATA  VECTOR  CONTAINING  THE  TEXT  at/ 
/at  PORTION  OF  TIIE  SIZE  MSG  FIELD  OF  at/ 

/*  THE  STATUS  LINE.  */ 

DECLARE  MTSSMESSAGE  DATA  C ’ 


DECLARE  SIZESMESSAGE  DATA  <’K  MTS  ’) 


/"*  * X * * * * X * X * X *******  */ 
/*  THE  NEXT  FOUR  DECLARATIONS  PROVIDE  THE  POINTERS  */ 
/at  UTILIZED  TO  CONTROL  THE  INPUT/ OUTPUT  AT  EACH  */ 
/*  TERMINAL.  */ 
/at  CURSOR  - SPECIFIES  THE  CURRENT  ADDRESS  WHERE  THE  */ 
/*.  CUP.SOR  IS  TO  BE  DISPLAYED.  «/ 
/*  CURRENTSLINE  - ADDRESS  WHICH  POINTS  TO  INITIAL  BYTE  */ 
/a:  OF  CURRENT  USER  INPUT  LINE.  THIS  LINE  HAS  at/ 
/at  NOT  YET  RECEIVED  A ’CR’  AND  THUS  IS  NOT  YET.’:/' 
/at  CONSIDERED  AN  INPUT  BUFFER.  */ 

✓ at  NEXT? CHAR  - POINTS  TO  NEXT  CHAR  TO  BE  PROCESSED  FROM1"/ 

✓ at  THE  INPUT  BUFFER.  AN  INPUT  IS  DEFINED  AS  A */ 
✓at  STRING  OF  iiSCII  CHARACTERS  (FROM  I TO  512)  */ 
✓at  WHICH  HAS  BEEN  TERMINATED  BY  A ’CR’  OR  «/ 
/at  ’ MTSSCMD’  KEY  BY  THE  USER.  */ 
/at  ENDSIBUFF  - POINTS  TO  BYTE  POSITION  IN  INPUT  BUFFER  */ 
/at  WHERE  ’CR’  OR  ’MTSSCMD’  WAS  RECEIVED.  */ 


BYTE  INITIALCO, 0,0, 0,0, 0,0,0) 
BYTE  I N IT I AL( 0,0, 0,0,0, 0,0,0) 
BYTE  INITIALCO, 0,0, 0,0, 0.0,0) 
BYTE  INITIALCO, 0,0, 0,0. 0.0,0) 


DECLARE  CURSOR  ( B) 
DECLARE  CURRENTSLINE  ( B) 
DECLARE  NEXTSCHAR  (8) 
DECLARE  ENDSIBUFF  ( 0) 


/at  CAPITALIZE  - SET  TO  ONE  IF  TERMINAL  IN  CAP  MODE  */ 


CONTAINS  THE  CURRENT  STATUS  OF 
EACH  TERMINAL’S  INPUT  BUFFER, 
EITHER  INPUT  WAITING; 

MTS  CMD  READY;  OR  I BUFF  EMPTY. 


/*  TERMSSTATUS 


DECLARE  TERMSSTATUS  (4)  BYTE  INITIAL  ( I I BUFFS EMPTY! 
I I BUFFSEMPTYI . I IBUFFSEMPTY) , I IBUFFSEMPTYI ) ; 


FOR  EACH  TERMINAL  THERE  IS  A ONE  BYTE  */ 
SAVE  AREA  WHICH  IS  USED  DURING  CURSOR  */ 
BLINKING  PROCESSING  */ 


DECLARE  SWAPSPOS  (4)  BYTE  INITIAL  ( T CURSORSCHAR] 
I CURSORSCHAR] , I CURSORSCHAR]  , C CURSORSCHAR] ) ; 


EOF 

/atatatatatatatatatstatajacatatatstatataistatatatattitatatatatHtatatatatatatafatatatatacatatKatatii:**;!:/ 
/Kata:  TERMINAL  INTERFACE  UTILITY  PROCEDURES  atatatatata:*/ 

/atatataeatatacacatacatacatatatatataeatasattfcatatatatatatfcatatataeatatatatatacatatatatat**:*:*:**** 


OFFH 


I MACRO  TRUE 
C MACRO  FALSE 
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[MACRO  SVAPSPOS 


’ 1 1FDH’ ] 


COMPARESPTRS:  PROCEDURE; 

/*XXXX*XXX*X********X*****X**X**X**X*XX****X***#*****/ 

/■*  COMPARES  TVO  POINTERS  (2  BYTES  EACH)  TO  DETERMINE*/ 


/*  IF  THEY  ARE  EQUAL.  */ 
/*  INPUT:  DE  - ADDRESS  OF  FIRST  PTR  */ 
/*  IIL  - ADDRESS  OF  SECOND  PTR  */ 
/*  OUTPUT:  A - TRUE  IF  EQUAL,  FALSE  OTHERWISE.  */ 
/*  CALLED  BY:  KEY3C0NMAND ; READSTERMINAL;  */ 


/****************************************************/' 

CY=0; 

IF  ( A=M(DE)—  M(ML) ) ’ZERO  THEN 
A=  I FALSE] 

ELSE 

DO; 

DE=  DE+ 1 ; HL=  HL+ 1 ; 

IF  ( A=M(  DE) — M<  HL) ) IZERO  THEN 
A=C FALSE] 

ELSE 

A=  [ TRUE] ; 

END; 

END  COMPARESPTRS; 


CON VERT3NUMBRST0S ASC 1 1 : PROCEDURE ; 

/tf******^********************************:'***********/ 
CONVERTS  THE  SPECIFIED  NUMBER  TO  A DISPLAYABLE  */ 


/*  TWO  DIGIT  DECIMAL  NUMBER  (MAX  VALUE  IS  99).  *s 
/*  INPUT:  A - NUMBER  TO  BE  CONFUTED.  */ 
/*  OUTPUT:  D - LEFT  MOST  DiGIT  TO  BE  DISPLAYED.  */ 
/»  C - RIGHT  MOST  DIGIT  TO  BE  DISPLAYED.  *s 
/*  CALLED  BY:  SIZESMSG;  STATUSSMSG;  */ 


/******j**W{****«**>»*»*»***s*******«*s***********// 

B=  0 ; C=  A; 

DO  WHILE  (A:: 10)  PLUS; 

B=  B+  1 ; 

C=( A=C-IO) ; 

END; 

C=(  A=A+30H) ; 

B=(  A=B+30H) ; 

END  CON VERTSNUMBRSTOS ASC 1 1 ; 


GETS  INDEX:  PROCEDURE; 

/*#********:*************:M:*******:M:***:***************/ 


/*  USED  TO  GET  THE  INDEX  INTO  AN  ADDRESS  ARRAY  BY  */ 
S*  COMPUTING  THE  OFFSET  FROM  A GIVEN  BASE  ADDRESS.  */ 
/*  INPUT:  A - OFFSET  VALUE  (NORMALLY  THE  TASK  OR  */ 

/*  TERMINAL  NUMBER) . *' 

/*  HL  - BASE  ADDRESS  *' 

/*  OUTPUT:  DE-  ARRAY  OFFSET  */ 

/*  HL-  ARRAY  OFFSET  ( HL=  DE)  */ 

/*  BC-  COMPUTED  OFFSET  */ 

/*  CALLED  BY:  SCROLLSDISPLAY;  UPDATESCURSOR;  */ 

/*  KEYSCOMMAND;  TERMS INPUTSCNTL;  */ 

/*  READSTERMINAL;  WRITES  TERM  INAL 

/-S***************************************************/ 

CY=0 ; B=0; 

C= ( A=<  < A) ; /*  SET  ADDRESS  OFFSET  TO  0FFSET*2  */ 

HL=HL+BC;  DE=HL; 

END  GETS  INDEX; 


GETS VALUE : PROCEDURE; 

/****:(:*****************#*****************************/ 


/*  GETS  A 2 BYTE  VALUE  FROM  MEMORY.  */ 
/*  INPUT:  DE  - ADDRESS  OF  2 BYTE  VECTOR;  THE  */ 
/%  CONTENTS  ARE  TO  BE  STORED  IN  THE  */ 
/*  HL  REGISTER.  *' 
/*  OUTPUT:  HL  - CONTENTS  OF  2 BYTE  VECTOR  */ 
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/*  DE  - ADDRESS  OF  THE  HIGH  ORDER  BYTE  */ 

/*  CALLED  BY:  SCR0LL3DISPLAY;  UPDATESCURSOR;  */ 

/*  KEYSCOMMAND ; READSTERM I NAL ; */ 

/*  WRITE8TERMINAL;  GETSD I SPLAYS ADDR  */ 

/*#*********************#*****###****##**************/' 
L=  ( A=  M(  DE)  ) ; DE=DE+1:  H=  ( A=M<  DE) ) ; 

END  GET# VALUE; 


STORES VALUE:  PROCEDURE: 


/*  STORE  A 2 BYTE  VALUE  INTO  MEMORY.  */ 
/*  INPUT:  HL  - VALUE  TO  BE  STORED  INTO  MEMORY  */ 
/*  DE  - ADDRESS  OF  HIGH  ORDER  BYTE  */ 
/*  CALLED  BY:  UPDATESCURSOR;  KEYSCOMMAND;  */ 
/*■  READSTERM  I NAL;  WRITES  TERM  I NAL;  */ 
s*  GETSD ISPLAY3ADDR;  */ 


M(DE)=(A=H);  DE=  DE- I : M(DE)=(A=L>; 
END  STORESVALUE; 


MOVESBYTES:  PROCEDURE; 

/*******:):*****:!:  :M::|::i:***:ie*******:K**:*:|t!f::t::#***S:**#*#******/' 

/*  MOVES  BYTES  OF  DATA  FROM  ORE  MEMORY  LOCATION  TO  */ 


/*  ANOTHER.  */ 

INPUT:  BC  - NUMBER  OF  BYTE  TO  BE  MOVED.  */ 

/*  DE  - STARTING  MEMORY  ADDRESS  TO  MOVE  */ 

/*  BYTES  TO  (DESTINATION).  */ 

/*  HL  - STARTING  MEMORY  ADDRESS  TO  MOVE  */ 

/*  BYTES  FROM  ( SOURCE) . */ 

/*  CALLED  BY:  SIZESMSG;  MTSSMSG;  */ 


/-************:#*:|c*******«:***:f:**:<c**:f::*:*****:****:*::K*:*#::****/' 

REPEAT; 

M(  DE)  = ( A=M<  HL) ) ; 

DE=  DE+ 1 ; HL=HL+ 1 ; 

BC=BC-1;  A=0: 

UNTIL  (A::B)  ZERO  (A::C)  ZERO; 

END  MOVESBYTES; 


SWAPSCURSOR:  PROCEDURE; 

/*»**»:**»c*******^***^*«*****^************************/ 
/*  SWAP  THE  SPECIFIED  TERMINAL’S  CURRENT  CURSOR  */ 
/*  POSITION  CHAR  WITH  THE  SWAPSPOS  CHAR.  *' 

/*  INPUT:  A - TERMINAL  NUMBER  */ 

/*  HL  - DISPLAY  ADDRESS  OF  CURSOR  POSITION  */ 

/*  CALLED  BY:  BL I NK3CURS0RS ; CHECKSCURSOR;  */ 

DE=  HL ; /*  SAVE  DISPLAY  ADDRESS  */ 

B=0;  C=  A; 

HL^CSWAFOPOSI+BC;  GET  SWAP  ADDRESS  */ 

B=  ( A=  M(  DE) ) ; ✓*  SWAP  */ 

M(  DE)  = ( ASM(  HL)  ) ; 

M(HL)  = (A=B)  ; 

END  SWAPSCURSOR; 


EOF 

/*******:fc****:t:***c*****:!:*****:.,:*:*****:|:**************5i::**.' 

/********  TERMINAL  INTERFACE  PRIMITIVES  ************/ 

/*********:fc*:**:M!:f:*****:fc***:f:********:***:*:|t#**#*:#::l:**:K***/ 


[MACRO  TRUE 
(MACRO  FALSE 
[MACRO  BLANK 
[MACRO  I BUFFS EMPTY 
r MACRO  DISPLAY8SIZE 
[MACRO  TERM9P0RT 
[MACRO  CURSORSCHAR 


’ OFFH’  1 
*0'  1 
’20H’  I 
’0’  I 
’512’  I 
’ 03FH’  1 
’ 05FH’  I 
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s'*********************************************** *****/ 

^***t**tiM«»t***  INTERNAL  LINKAGE  MACROS  v*************,/- 


[ INT  TBI  CTB  :=  1000H3 


I MACRO 

STATUS8BASE 

’[HEX 

TB 

+ 

0 106HI ’ ] 

I MACRO 

D I SPLAY8BASE 

’[HEX 

TB 

+ 

0 1 1 1 HI  ’] 

C MACRO 

CURSOR 

’[HEX 

TB 

+ 

01D5HI  ’] 

[MACRO 

CURRENTSLINE 

’[HEX 

TB 

+ 

OIDDHI  ’ I 

[MACRO 

NEXT3CHAR 

’[HEX 

TB 

+ 

01E5H1 ’ ] 

[MACRO 

ENDS  I BUFF 

’[HEX 

TB 

+ 

01EDHI ’ I 

[MACRO 

TERM8STATUS 

’ [HEX 

TB 

+ 

01F9HJ ’ ] 

[MACRO 

GET9 INDEX 

’ [HEX 

TB 

♦ 

024CHI • I 

[MACRO 

GET8VALUE 

’[HEX 

TB 

+ 

0259HI ’ I 

[MACRO 

ST0RE8 VALUE 

’[HEX 

TB 

+ 

0262HI ’ ] 

[ MACRO 

SWAPSCURSOR 

’[HEX 

TB 

027EHI ’ ] 

BLANKS D I SPLAY : PROCEDURES 

/***#************#***************:;:*******************/ 


/*  PLACES  BLANKS  INTO  THE  INDICATED  AREA  OF  A */ 
/*  TERMINAL  DISPLAY.  */ 
/*  INPUT!  BC  - STARTING  ADDRESS  (RANGE  O TO  U 1 1 ) */ 
/*  DE  - NUMBER  OF  BYTES  TO  SET  TO  BLANK  */ 
/*  HL  - BASE  ADDRESS  */ 
/*  CALLED  BY:  KEY3C0MMAND;  SCR0LL8DISPLAY;  */ 
/*  CLEAR3STATUS8L  I NE ; MTSSNSC;  */ 


/*:fc#*****:S*:K**«**:K*:(:*****:fc*:t:*Sc:|:: ft*********************/ 
IIL-  HL+BC ; 

REPEAT; 

M(  HL) « C A=  £ BLANK}  ) ; 

HL=  HL+  1 ; 

DE=DE- 1 ; 4=0; 

UNTIL  ( A: : D)  ZERO  ( Ai : E)  ZERO; 

END  CLANKSD ISPLAY ; 


GETSD I SPLAYS ADDR:  PROCEDURE; 

/'*******************:l:*******:*:|c**********:****#********/ 

/*  GETS  A MEMORY  ADDRESS  IN  THE  DISPLAY  BUFFER  USING*/ 
/*  THE  DISPLAY  BUFFER  PTR  AS  OFFSET  FROM  THE  DISPLAY*/ 


/*  BASE  ADDRESS.  */ 

/*  INPUT:  BC  - TERMINAL  NUMBER  OFFSET.  */ 

/*  DE  - ADDRESS  OF  DISPLAY  BUFFER  PTR  */ 

/*  OUTPUT:  HL  - MEMORY  ADDRESS  IN  DISPLAY  BUFFER.  */ 

/*  BC  - DISPLAY  PTR  VALUE.  */ 

/*  CALLED  BY:  TERM* INPUT8CNTL;  KEY8C0MMAND ; */ 

/*  BLINK8CURS0RS;  READ8TERM I NAL ; */ 

/*  VRITE8TF.RMI  NAL;  */ 

/I****************************************************/ 

DECLARE  PTR(  2)  BYTE; 

CALL  £ GETSVALUEI ; 

PTR=HL;  /*  SAVE  DISPLAY  PTR  VALUE  */ 

DE=(HL=£DISPLAY8BASEJ+BC) ;/*GET* VALUE  PARAMETER  */ 
BC=  ( HL=  PTR) ; /*  GET  DISPLAY  PTR  VALUE  */ 

CALL  £ GET8VALUE] ; /*  GET  DISPLAY  BASE  */ 

HL= HL+BC;  /*  GET  DISPLAY  ADDRESS  */ 

END  GETSD ISPLAY*ADDR; 


CHECK* CURSOR:  PROCEDURE; 

/'*****:.>:#**:)!:.■:**:}:**-************************************/ 
/*  PRIOR  TO  CHANCING  THE  CURRENT  CURSOR  POSITION  OR  */ 
/*  DISPLAYING  A CHARACTER  AT  THE  CURRENT  CURSOR  POS,*/ 


/*  A CHECK  IS  ALWAYS  MADE  TO  ENSURE  THAT  THE  */ 
/*  CURRENT  DISPLAY  IS  A DATA  CHARACTER  AND  NOT  THE  */ 
/*  CURSOR  ITSELF  (l.E.  5FH) . IF  IT  IS  THE  CURSOR  */ 
/*  A SWAP  IS  MADE.  */ 
/*  INPUT:  A - TERMINAL  NUMBER  */ 
/*  CALLED  BY:  KEY9C0MMAND;  TERM* INPUTSCNTL;  */ 
/*  WRITESTERMINAL;  */ 
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✓************************************«***************/' 
DECLARE  T BYTEs 
T=  As  HL=  C CURSOR] ; 

CALL  [GETS INDEXES 
CALL  CET8D I SPLAY# ADDR ; 

IF  <A=M(HL>;  A: : CCURS0R8CHAR] ) ZERO  THEN 
DO; 

A=T; 

CALL  C SWAPSCURSOR] ; 

END; 

END  CHECKSCURSOR; 


GET89TATJSSADDR:  PROCEDURE; 

/#x*#*xxxx#xx***x*x*x*x***************x****#*********/ 
/*  GETS  THE  BASE  ADDRESS  OF  THE  STATUS  LINE  FOR  THE  */ 


/*  SPECIFIED  TERMINAL. 

/*  INPUT:  A - TERMINAL  NUMBER  */ 
/*  OUTPUT:  IIL  - MEMORY  ADDRESS  OF  FIRST  BYTE  IN  */ 
/*  STATUS  LINE.  */ 
s*  CALLED  BY:  CLEAR3STATUS3LINE;  MTSSMSG;  *' 
/*  SIZE8MSG;  STATUSSMSG;  */ 


HL=  l STATUS3BASE] ; 

CALL  C GET? INDEX] ; 

GALL  [ GETSVALUE] ; 

END  GETSSTATUSSADDR; 

GET8TFRM3STATUS:  PROCEDURE; 

/X**XX*XX*X****X*XXXXX*X****X*****X*********X*******'*/' 
S*  RETR I EVES  THE  TERMINAL  STATUS  FOR  THE  INDICATED 


/*  TERMINAL.  TERMINAL  STATUS  SPECIFIES  WHETHER 
/*  OR  NOT  THERE  IS  AN  INPUT  BUFFER  OR  MTS  COMMAND  */ 
READY  FOR  PROCESSING  FOR  THAT  TERMINAL.  */ 

/*  INPUT:  A - TERMINAL  NUMBER  *' 

/*  OUTPUT:  A - TERMINAL  STATUS  */ 

/*  CALLED  BY:  KEYSCOMMAND;  TERMINAL8STATUS; 

UPDATE9CURSOR;  MONITOR  (MON  MOD); 


/XX*XX*XXX*XX*X***XXXXXXX*********X*********X********/ 

B=0;  C= A; 

HL= C TERMS STATUS] +BC ; 

A=M(HL)  ; 

END  GET3TERMSSTATUS ; 


SCR0LL8D I SPLAY : PROCEDURE; 

/XXX?-KXX*X*XX***X**XX**XX***X*******X****************/ 

/*  SCROLLS  THE  DISPLAY  FOR  THE  INDICATED  TERMINAL.  */ 
/*  INPUT:  A - TERMINAL  NUMBER  *' 

/*  CALLED  BY:  UPDATESCURSOR  *' 

/XXXXXXXXXXXX.XXXXX*************-*-*********************/ 

DECLARE  TERM  BYTE; 

DECLARE  POS( 2)  BYTE; 
fERM= A ; HL=  [ D I SPLAY8BASE] ; 

CALL  tGET* INDEX]; 

CALL  [GETSVALUE];  DE=HL;  //*DE= DISPLAY  BASE  ADDR  */ 
POS-HL;  ✓*  SAVE  DISPLAY  BASE  ADDRESS*'" 

BC=64; 

BC= ( HL=HL+BC) ; /*  BC= DISPLAY  BASE  + 64  */ 

HL=448; 

REPEAT; 

M(  DE)  = ( A- M(  BC)  ) ; 

BC=BC+l;  DE=  DE+ 1 ; 

HL=  HL-  1 ; A=  0 ; 

UNTIL  (A::H)  ZERO  (A::L)  ZERO; 

BC=^'»3;  /*  SETUP  PARAMETERS  FOR  */ 

DE*  64 ; HL=POS;  /*  BLANK8D I SPLAY  PROC  *^ 

CALL  BLANKS D I S PLAY ; 

END  SCROLL8DISPLAY; 
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SENDS BEEP:  PROCEDURE! 

/****#  ***********************************************/ 


/*  SENDS  A BEEP  TO  THE  INDICATED  TERMINAL.  */ 

/*  THE  FORM  OF  THE  TERMINAL  ALERT  CONTROL  BYTE  IS:  */ 

/*  76543210  */ 

/•*  */ 

/*  I A3IC3IA2IC2I A1 IC1 I AOICOI  */ 

/*  */ 

/*  WHERE:  */ 

/*  A( I > = 1 i GENERATES  AN  ALARM  AT  STATION  I.  */ 

/*  C(I)  = It  GENERATES  A CLICK  AT  STATION  I.  */ 

/"*  INPUT:  A - TERMINAL  NUMBER  */ 

/*  CALLED  BY:  KEYSCOMMAND;  */ 


//**************************************:.‘:*:!c***:fc*****:S*/ 
H=0;  L= A; 

IF  (A: : 0)  PLUS  (A:: 4)  MINUS  THEN 
DO  CASE  HL; 

OUT( I TERMSPORTI  ) = ( A=2) s 
OUT( I TERMSPORTI ) = C A=  0) ; 

OUT(  I TERMSPORTI  ) = ( A=  20H)  ; 

OUT(  [ TERMSPORTI ) = ( A=  80H) ; 

END; 

END  SENDS BEEP ! 


SENDSCLICK:  PROCEDURE: 

//****.f:*:S**:fc******:f:*:f:*:,,:*:J:*!t::.,:*:|e:f:*:t::!;***:t:*********:K*:S****/ 


/*  SENDS  A CLICK  TO  THE  INDICATED  TERMINAL.  SEE  */ 
/*  SEND3BEEP  PROC  FOR  DEFINITION  OF  TERMINAL  ALERT  */ 
/*  CONTROL  BYIE.  */ 
/*  INPUT:  A - TERMINAL  NUMBER  */ 
/*  CALLED  BY:  UPDATESCURSOR  */ 


/'*:|:*:je******:it:|c#*********>K****:f::***:fc*:*::K:fc******:*:):********// 

H=0;  L=Ai 

IF  (A: : 0)  PLUS  (A:: 4)  MINUS  THEN 
DO  CASE  HL: 

OUT(  C TERTIS P0RT1  ) = ( A=  1 ) ; 

OUT( [ TERMSPORTI ) = < A=4> ; 

OUT(  I TERMSPORTI ) = ( A= 10H) ; 

OUT( C TERMSPORTI ) = C A=40H) : 

END: 

END  SENDSCLICK; 


UPDATESCURSOR:  PROCEDURE; 

/*#*************************************************:*/ 
/*  CONTROLS  THE  UPDATING  OF  THE  CURSOR  POSITION.  THE*/' 
/*  PRIMARY  CONCERN  IS  TO  CHECK  FOR  SCROLLING  PRIOR  */ 
/*  TO  UPDATING  THE  CURSOR.  SCROLLING  IS  NOT  ALLOWED  */ 
/*  IF  SCROLLING  WILL  DESTROY  ANY  INPUT  DATA  NOT  YET  */ 


/*  PROCESSED . */ 
/*  SUBPROCEDURES:  CHECK8SCR0LLSL0CK0UT  */ 
/*  UPDATESD I SPLAYSPTRS  */ 
/*  INPUT:  A - TERMINAL  NUMBER  */ 
/*  HL  - VALUE  TO  WHICH  CURSOR  POSITION  IS  */ 
/*  TO  BE  SET.  */ 
/*  CALLED  BY:  KEYSCOMMAND:  TERMS I NPUTSCNTL ; */ 
/*  WRITESTERMINAL;  */ 


/*****:*:*************:l!**##**#***##******#*************/ 

DECLARE  T BYTE; 

DECLARE  POS( 2)  BYTE: 

CHECKSSCR0LL3L0CK0UT:  PROCEDURE: 
,/************************************************/ 
/*  CHECKS  TO  SEE  IF  THERE  IS  AN  INPUT  BUFFER  */ 
/*  READY.  I.’  SO.  CHECKS  TO  SEE  IF  SCROLLING  WILL*/ 
/*  DESTROY  INPUT  BUFFER.  IF  SO,  RETURN  TRUE,  */ 
/*  ELSE  RETURN  FALSE.  */ 

/*  OUTPUT:  A - TRUE  IF  SCROLLING  IS  LOCKED  OUT  */ 
/***»********************************************/ 
A=T; 

CALL  GF.TSTERMSSTATUS : 
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IF  ( A=A-I  IBUFFSEMPTY] ) tZERO  THEN 

DO;  /*  CHECK  NEXTSCHAR  PTH  */ 

A=T;  HL=[ NEXTSCHAR] ; 

CALL  CCET3 INDEX]  ;/*  GET  NEXTSCHAR  OFFSET*/ 
CALL  C CET3VALUE] ; /*  GET  NEXTSCHAR  VALUE*/ 
BC=  -64;  CY=Oi 

IF  ( HL=HL+BC)  CY  THEN  /*  SCROLL  OK  */ 

A=C FALSE] 

ELSE  /*  SCROLL  LOCKEDOUT  */ 

A*  C TRUE] ; 

END 

ELSE  /*  NO  INPUT  BUFFER,  SCROLL  OK  */ 

A= I FALSE] ; 

END  CHECKSSCROLLS LOCKOUT; 


UPDATESD I SPLAYSPTRS : PROCEDURE; 
/************************************************/ 
/*  UPDATES  ALL  DISPLAY  PTRS  TO  REFLECT  THE  */ 

/*  SCROLLING  OF  THE  DISPLAY.  USES  SETSPTR  TO  */ 
/*  DECREMENT  AND  STORE  THE  POINTER  VALUES.  */ 

/*  SUBPROCEDURE:  SETSPTR;  */ 

/****#*.-S*********s-.:.‘:***:fc:j:*:s*******:**:>:*:(:*:t:*****:K:t:**/ 

SETSPTR:  PROCEDURE; 

/*  ***********  fc*************************:):***#*/ 

/*  SETS  THE  SPECIFIED  PTR  TO  PTR-64,  AND  */ 
/*  STORES  THE  RESULT.  */ 

/*  INPUT:  DE  - ADDRESS  OF  PTR  */ 

/**#********:t:**:K**:c*****:K*:f:**:fc:»:  :********:******/ 

CALL  I GETSVALUE1  ; 

BC=-64;  IIL=  HL+BC ; 

CALL  C STORES VALUE] ; 

END  SETSPTR; 


/********************************************/ 
/*  START  OF  UPDATESD ISPLAY3PTRS  PROCESSING  */ 

/SR*****:**:*  ;*:«:*»**:**»*«:*:«****:****:«*************/ 


/*  SET  CURSOR  TO  LEFT  MARGIN  OF  8TH  LINE*/ 
/*  ON  DISPLAY.  */ 

A=T;  HL=[  CURSOR]; 

CALL  [GETS  INDEX]; 

HL=448;  DE - DE+ 1 ; 

CALL  l STORESVALUE] ; 

/*  SET  NEXTSCHAR  = NEXTSCHAR  - 64  */ 

DE=  ( HL= C NEXTSCHAR]  +BC) ; 

CALL  SETSPTR; 

/*  SET  CURRENT8LINE  = CURRENTSLI’IE  - 64  */ 
A=T;  HL=CCURRENTSLINE] ; 

CALL  [GETS INDEX]; 

CALL  SETSPTR; 

/*  SET  ENDS  I BUFF  = ENDS  I BUFF  - 64  */ 

A=T;  HL= I ENDS  I BUFF] ; 

CALL  [GETS INDEX]; 

CALL  SETSPTR; 

END  UPDATESD I SPLAYSPTRS; 

/************************************************/ 
/*  START  OF  UPDATE3CURS0R  PROCESSING  */ 

/'*****:*******************:***:l:********************/ 

T= A;  /*  SAVE  INPUT  TERMINAL  NUMBER  */ 

POS=  HL;  /*  SAVE  INPUT  CURSOR  POSITION  */ 

BC=  -C  DISPLAYSS IZE] ; CY=0; 

IF  ( HL=  HL+OC)  CY  THEN  /*  SCROLLING  REQUIRED  */ 
DO; 

CALL  CHECKSSCROLLSLOCKOUT; 

IF  ( A=>  > A)  CY  THEN  /*  SCROLLING  LOCKED  OUT  */ 
DO; 

A=T; 

CALL  SENDSCLICK; 
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END 

ELSE  /*  SCROLLING  IS  OK  */ 

DO; 

A«T; 

CALL  SCROLLED I SPLAY; 

CALL  UPDATE8D I SPLAY# PTRS ; 

END; 

END 

ELSE  /*  NO  SCROLLING  REQUIRED;  UPDATE  CURSOR  */ 
DO; 

A=T;  HL=  I CUPSORI  ; 

CALL  [GETS INDEX!;  GET  CURSOR  PTR  ADDR 

HL=  POS ; /*  SETUP  C STORES VALUE]  PARAMETERS 
DE»  DE+ 1 ; 

CALL  I STORES VALUE] ; UPDATE  CURSOR  PTR 
END; 

END  UPDATESCURSOR; 


*/ 

#/ 


EOF 

/#***#*«**********:«****:******:f.:.':*:Ms*:,’ :*#***:***  **  a.******/ 
/******  TERMINAL  KEY  PROCESSING  PROCEDURES  ********* 
/**********************:****#*************:.•***********/ 


[MACRO 
[MACRO 
[MACRO 
[MACRO 
[ MACRO 
[ MACRO 
[MACRO 


TRUE 

FALSE 

BLANK 

CURS0R3CHAR 
INPUTS WAITING 
MTSSCMDSRF.ADY 
IBUFFSEMPTY 


’ 0FFH’ ] 
’©•  I 
’20H’  J 
’3Fn’  ] 
' 0FFH’ ] 
’ OF0H’ ] 
'O’  ] 


/*****#************  X«:XX**%XXXXXXX**X*X*X'J:*Z***XX*****/ 

***********  MTS  KEY  COMMAND  MACROS  ****************/' 


[ MACRO 

MTSSCMD 

OAOH’ I 

[MACRO 

CR 

ODH’  ] 

[MACRO 

CHAR8DELETE 

07FH’ ] 

[MACRO 

LINES DELETE 

0 15H’  ] 

[MACRO 

CAPITAL 

0A1H’ ] 

[MACRO 

CURSORS LEFT 

0A2H’ ] 

[MACRO 

CURSORSRIGHT 

0A3H’ ] 

[MACRO 

CLEARSSCREEN 

0A4H’ ] 

s****************************************************/' 

/***** 

INTERNAL  AND  EXTERNAL 

LINKAGE  MACROS  *******/ 

[ INT  GB  TB]  [GB  :=  0] 

[TB 

1000H] 

[MACRO 

TCT8STATUS 

’[HEX 

GB 

+ 

3E95H1 ’ ] 

[MACRO 

ASCII 

’[HEX 

TB 

4* 

0003H] ’ ] 

[ MACRO 

DISPLAY8BASE 

’[HEX 

TB 

+ 

Oil 1H] ’] 

(MACRO 

CURSOR 

’[HEX 

TB 

4* 

01D5H] ’] 

[MACRO 

C URRENT8L IRE 

’[HEX 

TB 

+ 

01DDH] ’] 

[ MACRO 

NEXTSCHAR 

’ [ HEX 

TB 

4* 

01E3H] ’ I 

[ MACRO 

ENDS I BUFF 

’[HEX 

TB 

■f 

01EDH] ’] 

[MACRO 

CAPITALIZE 

’[HEX 

TB 

4* 

01F3H] ’] 

[ MACRO 

SWAPSPOS 

’(HEX 

TB 

4* 

01FDH] ’ ] 

(MACRO 

COMPARESPTRS 

’[HEX 

TB 

+ 

0213H] ’] 

[MACRO 

GETS  INDEX 

’ [ HEX 

TB 

+ 

024CH] ’ ] 

[ MACRO 

GETS VALUE 

’ [HEX 

TB 

4* 

0239H] ’ ] 

[MACRO 

STORESVALUE 

’[HEX 

TB 

4* 

026211] ’ ] 

[ MACRO 

BLANK8DISPLAY 

’ [ HEX 

TD 

4* 

02A3H1 ’ 1 

[ MACRO 

GETSD I SPLAYS ADDR 

’[HEX 

TB 

4* 

02B7H] * ] 

[MACRO 

CHECKSCURSOR 

’[HEX 

TB 

4* 

O2D0H] ’ ] 

[ MACRO 

GETSTERM8ST  ATUS 

’[HEX 

TB 

4* 

02F9H] ’ ] 
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[ MACRO  SENDSBEEP  ' [ HEX  TB  + 033EB] ’ ] 

[ MACRO  UPDATESCURSOR  ’ C HEX  TB  + 03C2H3 ' ] 


KEYSCOMMAND:  PROCEDURE; 

/'I******;***:***********:***:**********:***:*?:*****:*****:***:*/' 


/* 

CHECKS  FOR  A 

TERMINAL  KEY  COMMAND  FOR  EVERY  KEY 

H/ 

/* 

INTERRUPT  RECEIVED. 

Hi/ 

/Hi 

KEY  COMMANDS 

ARE: 

Hi/ 

/X 

CMD 

KEY 

RESULT 

X/ 

/X 

— 

— 

*/ 

/X 

MTS  CMD 

ERROR  RESET 

SENDS  A COMMAND  TO 

X/ 

/Hi 

MTS  FOR  PROCESSING. 

Hi/ 

/* 

CR 

NEW  LINE; 

TERMINATES  THE 

*/ 

/HU 

ENTER;  SHIFT 

CURRENT  LINE  AND 

Hi/ 

/Hi 

CR;  I/O  CTL  M; ESTABLISHES  IT  AS 

Hi/ 

/X 

THE  CURRENT  INPUT 

X/ 

/* 

BUFFER. 

*/ 

/* 

CHAR  DELETE 

BACK  SPACE 

DELETES  THE  LAST 

Hi/ 

/Hi 

CHAR  ENTERED. 

Hi/ 

/Hi 

LINE  DELETE 

NEXT  FMAT 

DELETES  THE  CURRENT 

H/ 

/* 

LINE. 

Hi/ 

/Hi 

CAPTIALIZE 

FS  C 

FLIP/FLOP  USED  TO 

Hi/ 

/* 

SET  OR  CLEAR  'HIE 

Hi/ 

/X 

TERMINAL  INPUT  MODE 

X/ 

SX 

TO  UPPER  OR  LOWER 

*/ 

/Hi 

CASE  LETTEPJ3 . 

*/ 

/* 

CLEAR  SCREEN 

FS  8 

CLEARS  THE  512  CHAR 

Hi/ 

/Hi 

DISPLAY  BUFFER. 

Hi/ 

/Hi 

CURSOR  LEFT 

< — 

MOVES  CURSOR  POS 

Hi/ 

/Hi 

ONE  POSITION  TO  THE 

Hi/ 

/Hi 

LEFT. 

H/ 

/Hi 

CUROSR  RIGHT 

> 

MOVES  CURSOR  POS 

*/ 

/Hi 

ONE  POSITION  TO  THE 

H/ 

/Hi 

RIGHT. 

*/ 

/Hi 

SUBPROCEDURES:  ACCEPTS  INPUT; 

CHECKSLEFTSMARG  I N ; 

Hi/ 

/Hi 

DELETE3CHAR; 

CLEAR3PTRS;  MTSSCMD; 

Hn/ 

/Hi 

TERM I NATESCL ; 

CARR I AGES RETURN ; 

*/ 

/* 

CRARSDELETE; 

LINE8DELETE;  CAPITAL; 

>*/ 

/Hi 

CLEAR8SCREEN; 

CURSORSLEFT; 

/Hi 

CURSORSRIGHT; 

CHECK8CASE; 

*/ 

/Hi 

INPUT:  A 

- TERMINAL  NUMBER 

*/ 

/Hi 

C 

- ASCII  CHAR  RECEIVED 

*/ 

/X 

OUTPUT:  A 

- TRUE  IF  CHAR 

= KEY  COMMAND 

*/ 

/Hi 

CALLED  BY: 

TERMS  I NPUTSCNTL ; 

*/ 

/'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/' 
DECLARE  ( CHAR, T)  BYTE; 

DECLARE  RESPONSE  BYTE; 

ACCEPTS  INPUT:  PROCEDURE; 

/************************************************/' 
/x  CHECKS  THE  TERMINAL’S  CURRENT  STATUS  TO  */ 

/*  DETERMINE  IF  THIS  NEW  INPUT  BUFFER  SHOULD  BE  */ 
/X  ACCEPTED.  IF  SO.  RETURNS  TRUE.  ELSE  FALSE.  */ 
/X  OUTPUT:  A - TRUE  IS  INPUT  CAN  BE  ACCEPTED.  X/ 
/*  HL  - IF  A IS  TRUE  THEN  HL  CONTAINS  */ 

/x  THE  ADDRESS  OF  TERM3STATUS.  */ 

/'******************:.':*****************************/ 
A=T;  CALL  C GET8TERM9STATUS I ; 

IF  ( A: : t IBUFFSEMPTYI ) IZERO  THEN 

DO;  /*  INPUT  BUFFER  HAS  NOT  YET  BEEN  */ 
/^PROCESSED ; DO  NOT  ACCEPT  NEW  BUFFER*/ 
A=T;  CALL  t SENDSBEEP]  ; 

A=t FALSE! : 

END 

ELSE 

A=  C TRUE] ; 

END  ACCEPTS  INPUT; 


CHECKS LEFTS  MARGIN:  PROCEDURE; 

/******:.’;*****y::.':*******;l:*******:S****:******;M:******/ 
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/*  CHECKS  TO  SEE  IF  CURRENT  LINE  IS  EMPTY.  */ 

/W  COMPARF.SPTRS  RETURNS  THE  APPROPRIATE  TRUE/  */ 
/*  FALSE  VALUE  IN  THE  A REGISTER.  */ 

/*  INPUT:  DE  - ADDRESS  OF  CURSOR  */ 

/*  BC  - COMPUTED  OFFSET  OF  TERM  NBR  */ 

/*  OUTPUT:  A - RETURNED  TRUE  IF  CURSOR  IS  */ 

/*  PRESENTLY  AT  LEFT  MARGIN.  */ 

/*********************: t:**************************/ 
HL=CCURRENTSLINE3+BCj/*HL=A DD  OF  CURRENTLINE*/ 
CALL  [ C0MPARE8PTRS) ; /*  COMPARE  */ 

/*  CURSOR  = CURRENTS L I NE  */ 
END  CHECKSLEFT9MARGIN; 


CLEARSPTR:  PROCEDURE; 

/************************************************/ 
/*  SETS  THE  VALUE  TO  THE  SPECIFIED  DISPLAY  */ 

/*  POINTER  TO  ZERO.  */ 

/*  INPUT:  HL  - ADDRESS  OF  THE  DISPLAY  PTR  */ 

/****************:**:l;**************:fc*******:,lc******/ 

M( HL) = ( A=0) ; HL=HL+ 1 ; M(  HL) = A; 

END  CLEARSPTR; 


DELETESCHAR:  PROCEDURE; 

/*:K*sl;***:!:**W******:;:*»:|c*****:f::t:**:|:***********:fc:):****/ 

/*  DECREMENTS  THE  CURRENT  CURSOR  POSITION  AND  */ 
/*  SETS  NEW  CUP.SOR  POSITION  DISPLAY  TO  BLANK.  */ 
/*  INPUT:  DE  - ADDRESS  OF  CURSOR  */ 

/*  BC  - COMPUTED  OFFSET  OF  TERMINAL  NBR  */ 

/*:*********:):******:K*******:K*:,,:*#:f:*****************/ 

CALL  [GETS VALUE] ; /*  GET  CURSOR  */ 

HL=  UL- 1 ; /*  DECREMENT  CURSOR  */ 

CALL  C STORES VALUE] ; /*  SAVE  NEW  CURSOR  POS  */ 
CALL  C GET8D I SPLAYS ADDRI ; /*  REPLACE  PRESENT  */ 
M(  HI.)  = ( A=  [BLANK]);  /*  CHAR  WITH  BLANK  */ 

END  DELETESCHAR: 

TERMINATESCL:  PROCEDURE; 

/*:S:**:fc******:K****:l::K******************************/ 


/*  TERMINATE  THE  CURRENT  LINE.  THE  SAME  */ 

/*  PROCESSING  IS  DONE  FOR  BOTH  AN  MTS  CMD  AND  */ 
/*  A CARRIAGE  RETURN  C CR)  SINCE  EACH  SPECIFIES  */ 
/*  THE  END  OF  INPUT  BY  THE  USER.  */ 

/**********************************************  **/ 
/*  CHECK  CHAR  PRESENTLY  BEING  */ 

/*  DISPLAYED  AT  CURSOR  POSITION  */ 
/*  PRIOR  TO  UPDATING  PTRS.  */ 

A=T;  CALL  [ CHECKSCURSOR] ; 

/*  END  OF  CURRENT  LINE;  UPDATE  */ 

/*  DISPLAY  POINTERS  FOR  NEW  INPUT  */ 
/*  BUFFER  AND  NEW  CURRENT  LINE.  */ 


/*  SET  ENDS  I BUFF= CURRENT  CURSOR  POS  */ 
A=T;  HL= [ ENDS  I BUFF ] ; 

CALL  (CET® INDEX); 

HL=[ CURSOR] +BC; 

BC=  DE ; DE=HL; 

CALL  [ CETSVALUE] ; 

DE=  BC+ 1 ; 

CALL  [ ST0RE8VALUE1 ; /*  ENDS  I BUFF= CURSOR  */ 
/*  MOVE  CURSOR  TO  BEGINNING  OF  */ 

/*  NEXT  LINE.  HL  CONTAINS  THE  */ 

/*  CURRENT  CURSOR  POSITION.  */ 

BC=64;  HL=  HL+BC ; /*  ADD  64  TO  CURRENT  POS:*/ 
L=(A=L  0COH);/*THEN  CLEAR  LOWER  6 BITS*/ 
A=T; 

CALL  [ UP DATE® CURS OR  I ; 

/*  SET  CURRENT  LINE  = NEW  CURSOR  POS*/ 
A=T;  HL=  [ CURRENT9LINE] ; 

CALL  [GETS  INDEX]; 

HL=t CURSOR] +BC; 

BC=DE;  DE=HL; 
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CALL  t GETSVALUE) ; 

DE=  BC+ 1 ; 

CALL  C STORESVALUE]  •,  /*CURRENTSL  INE*  CURSOR*/ 
END  TERMINATESCL; 


MTSSCMD:  PROCEDURE; 

✓**#****:f!******.-C*:HS************:f:**:f:*5fc:S:)c**:»:***:l:***/ 

/*  CHECK  TO  SEE  IF  THIS  INPUT  CAN  BE  ACCEPTED.  */ 
/*  IF  SO,  SET  TERMSSTATUS  TO  MTSSCMD3READY  AND  */ 
/*  SET  MCP  BIT  IN  TASK  CONTROL  TABLE  TO  ENSURE  */ 
S*  MCF  IS  CALLED  BY  THE  MONITOR  TO  PROCESS  THIS  */ 
/*  MTS  COMMAND.  *' 

/X***********************************************/' 

CALL  ACCEPTS  INPUT; 

IF  ( A=> > A)  CY  THEN 

DO;  /*  ACCEPT  INPUT  BUFFER  */ 

M(  HL) = ( A=  [ MTSSCNDS READY] ) ; 

B=0;  C=(A=T); 

HL=  t TCT3STATUS]  + BC; 

M<  HL)  = < A=  MI  HL)  N 2); 

CALL  TERMINATESCL; 

END; 

END  MTSSCMD; 


CARR I AGES RETURN:  PROCEDURE; 

/X********************:*******************:.'*******/ 
/*  USER  HAS  TERMINATE  CURRENT  LINE.  CHECK  TO  */ 
/*  SEE  IF  NEW  INPUT  BUFFER  CAN  BE  ACCEPTED.  IF  */ 
/*  SO,  SET  TERMSSTATUS  TO  INPUTSWAITING  AND  */ 

/*  TERMINATE  CURRENT  LINE.  *s 

/-XXX**XXX*XX:I:*********:K***********»*************X/ 

CALL  ACCEPTS  INPUT; 

IF  ( A=  > > A)  CY  THEN 

DO;  /*  ACCEPT  INPUT  BUFFER  */ 

M( HL)  = ( A=  C I NPUT3WA I T I NG] ) ; 

CALL  TERMINATESCL; 

END; 

END  CARRIAGES RETURN; 


CHARSDELETF,:  PROCEDURE; 

/X***********************************************/ 


/*  CHECK  TO  ENSURE  THAT  CURRENT  LINE  IS  NOT  */ 
/*  EMPTY.  THEN  DELETE  THE  PREVIOUSLY  ENTERED  */ 
/x  CHAR.  */ 
/*■  INPUT:  DE  - CURSOR  OFFSET  ADDRESS  */ 


/X***********************************************/ 
CALL  CHECKSLEFT8MARGIN; 

IF  ( A=  > > A)  CY  THEN 


DO; 

/*  CURRENT  LINE  EMPTY 

*/ 

A=T; 

CALL 

C SENDSBEEP] ; 

END 

ELSE 

DO; 

/*  DELETE  CHAR 

%/ 

A=T; 

CALL  r CHECKSCURSOR] ; 

A=T; 

HL= t CURSOR) ; 

CALL 

[GETS  INDEX) ; 

CALL 

DEI.ETE8CHAR; 

END; 

END  CHARSDELETE; 

LINESDELETE: 

PROCEDURE; 

/X**********************:.-*******  XXXX*XXXX***X**XX/ 

/*  CHECK  TO  ENSURE  THAT  CURRENT  LINE  IS  NOT  */ 
/■*  EMPTY.  IF  NOT.  THEN  DELETE  THE  CURRENT  LINE.*/ 
/*  INPUT:  DE  - CURSOR  ADDRESS  OFFSET  */ 
z************************************************/ 
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CALL  CHECKSLEFTSMARG IN ; 

IF  ( A=>  > A)  CY  THEN 

DO;  /*  CURRENT  LINE  EMPTY 

A=T; 

CALL  [ SENDSBEEP] ; 

END 


ELSE 


DO; 

A=T;  CALL  [ CHECK9CURS0R] 
DO  WHILE  ( A=  > > A)  !CY; 
A=T;  HL=[ CURSOR] 

CALL  [GETS INDEX! 

CALL  DELETESCHAR 
A=T;  HL=C CURSOR] 

CALL  [GETS  INDEX! 

CALL  CHECKSLEFTSMARG I N ; 
END; 


A=0; 


/*  GET  CURSOR  OFFSET 


END; 

END  LINES DELETE; 


%/ 


*/ 


CAPITAL:  PROCEDURE; 

/*********************«**************************/ 
/*  SET  OR  CLEAR  THIS  TERMINALS  CAPITALIZE  FLAG.  */ 

/IK*****:** t.  * S '-K * X * XXX  X X X XX  * M: :(c  * * ::<*'■<;  * * * * X * * / 

B=0;  C=(A=T);  HL=  £ CAPITALIZE] +BC ; 

M(HL)  = (A=MCHL>  Wl); 

END  CAPITAL; 


CLEAP.3SCREEN:  PROCEDURE; 

/*  CLEARS  THE  512  BYTE  DISPLAY  3UFFER  /AND  */ 

/*  REINITIALIZES  THE  DISPLAY  POINTERS.  */ 

/*  INPUT:  HL  - CURSOR  ADDRESS  */ 

/#****:«**  #*****:*«:  IK******:!;*************#**********/ 

CALL  CLEARSPTR;  /*  REINITIALIZE  DISPLAY  */ 

A=T;  HL- C CURRENTSL INE!  ; /*  PTRS  AND  TERMINAL  */ 
CALL  [GETS  INDEX!;  /*  STATUS.  */ 

CALL  CLEARSPTR; 

A=  T;  HL=  C NEXTSCHAR!  ; 

CALL  [GETS INDEX!; 

CALL  CLEARSPTR; 

A=T;  CALL  [ CETSTERMSSTATUS ! ; 

MC  HL)  = C A=  [ I BUFFSEMPTY!  ) ; 

/*  CLEAR  THE  DISPLAY  */ 

A=T;  HL= [ DISPLAYSBASE] ; 

CALL  C GETS  I NDEX!  ; 

CALL  CGETSVALUE!;  /*  DISPLAYSBASE  PTR  IN  HL*/ 
BC=0;  DE-5 12 ; /*  SETUP  INPUT  PARAMETERS  FOR  */ 
/*  [ BLANKSDISPLAY!  PROC  */ 

CALL  [BLANKSDISPLAY!: 

/*  RESET  SWAP8P0S  TO  CURS0R3CHAR  */ 

B=0;  C= ( A=T) ; 

HL= [ SWAP8P0S! +BC ; 

MC  HL) » ( A* [ CUHSORSCHAR] ) ; 

END  CLEARSSCREEN; 


CURSORSLEFT:  PROCEDURE; 

/***^;**********»c*:K-*:S*»:***********W***i':*****.f:****5i;/ 

/*  MOVES  THE  CURRENT  CURSOR  POSITION  BACK  ONE.  */ 
/*  CHECKS  TO  ENSURE  THAT  CURSOR  IS  NOT  ALREADY  */ 
/*  AT  THE  LEFT  MARGIN  OF  CURRENT  LINE.  */ 

/*  INPUT:  DE  - CURSOR  ADDRESS  */ 

/************************************************/ 
CALL  CHECKSLEFTSMARG IN; 

IF  ( A=>  > A)  CY  THEN 

DO;  /*  AT  LEFT  MARGIN;  SEND  BEEP  */ 

A=T; 

CALL  [SENDSBEEP!; 

END 
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ELSE 

DO;  . /*  DECREMENT  CURSOR  */ 

A=T;  CALL  [ CHECKSCURSOR] ; 

A=T;  IIL=  C CURSOR]  ; 

CALL  CCETS INDEX]  ; 

CALL  C GETSVALUE]  ; 

HL=  HL-  1 ; 

CALL  C STORESVALUE]  : 

END; 

END  CURSORS LEFT; 


CURSORSRICHT:  PROCEDURE; 

✓"a:******:;;****************************************/ 

/%  MOVE  THE  CURRENT  CURSOR  POSITION  FORWARD  ONE.*/ 
/*  INPUT:  DE  - CURSOR  ADDRESS  */ 

/************************************************/ 
A=T;  CALL  [ CHECKSCURSOR] ; 

A=T;  HL=  C CURSOR] ; 

CALL  [GETS  INDEX]; 

CALL  t CETMVALUE]  ; 

nL=  HL+  1 ; /*  SETUP  NEW  CURSOR  POS  */ 

A=T;  CALL  C UPDATE3CURS0R] ; 

END  CURSORSRIGHT; 


CHECKSCASE:  PROCEDURE; 

/***************:':*********•.“**********************/ 
/*  USES  A CASE  STATEMENT . INSTEAD  OF  ’ELSE  DO’  */ 
/*  'lo  CHFCX  FOR  THE  LAST  FOUR  KEY  COMMANDS.  IF  */ 
/*  NOT,  RESPONSE  IS  SET  TO  FALSE.  (NOTE:  CASE  */ 
/*  STMT  MUST  BE  USED  TO  GET  AROUND  MLBO ’ S PARSE  */ 
/*  STACK  OVERFLOW,  CAUSED  BY  TOO  MANY  ’ IF  THEN  */ 
/*  ELSE  DO’  STMTS.  */ 

/*  INPUT:  DE  - CURSOR  ADDRESS  */ 

/**»**S«******:!:*******«***************************/ 
H=0;  L=  ( A=CHAR-0A1H) ; /*  SETUP  CASE  OFFSET  «/ 
IF  ( A : : 0 ) PLUS  (A:: 4)  MINUS  THEN 
DO  CASE  HL; 

CALL  CAPITAL; 

CALL  CURSORSLEFT; 

CALL  CURSORSRIGHT; 

DO;  HL=DE;  CALL  CLEARSSCREEN ; END; 

END 

ELSE 

RESPONSE1 ( A= I FALSE] ) ; 

END  CHECKSCASE; 

/***:(:**:“.******************:«**********************/ 
/*  START  OF  KEYSCOMMAND  PROCESSING  */ 

/************************************************/ 

T= A;  CHAR=(A=C);  /*  GET  INPUT  PARAMETERS  */ 

RESPONSE= ( A= C TRUE] ) ; /*  INITIALIZE  RESPONSE  */ 

A=T;  HL=I CURSOR];  /*  GETS  INDEX  PARAMETERS  */ 

CALL  [GETS INDEX];  /*  CET  CURSOR  OFFSET  ADDRESS*/ 

IF  ( A=CHAR-[  MTSSCMD] ) ZERO  THEN  /*  MTS  CMD  */ 
CALL  MTSSCMD; 

ELSE  DO; 

IF  ( A=CHAR-ICR] ) ZERO  THEN  /*  CARRIAGE  RETURN  */ 
CALL  CARR I AGES RETURN 


ELSE  DO: 

IF  ( A=CHAR-[ CHARSDELETE] ) ZERO  THEN 

CALL  CHARS DELETE  /*  CHAR  DELETE  CMD  */ 

ELSE  DO: 

IF  ( A=CHAR-C LINESDELETE] ) ZERO  THEN 

CALL  LINESDELETE  /*  DELETE  LINE  CMD  */ 
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*x 

*x 

*x 


END;  END;  END;  X*  END  OF  ELSE  DO’S  *X 

A= RESPONSE; 

END  KEYSCOMMAND ; 


TERTIS  I NPUTSCNTL;  PROCEDURE; 

✓******************;K*:&*:!c*:f:***#*:t:*:(c*******************X 
X*  CONVERTS  THE  INPUT  MATRIX  CODE  TO  ASCII;  CHECKS  *X 


X*  FOR  CAP  I AL I ZAT I ON  AND  CONVERTS  LOVER  TO  UPPER  *X 
X*  CASE  LETTERS  IF  REQUIRED;  CHECKS  FOR  MTS  KEY  *X 

X*  COMMANDS;  IF  NOT  A KEY  CMD  THEN  THE  CHAR  IS  *X 

X*  DISPLAY  AT  THE  TERMINAL  AND  CURSOR  INCREMENTED.  *X 

X*  INPUT:  C - MATRIX  CODE  *x 

X*  E - TERMINAL  NUfIBER  *X 

X*  CALLED  BY:  TERM i NALSHLDR.  C INTERRUPT  MOD)  *X 

X**:fc*****:K***:!:******:R**:.!'******:t::l:***:l!*:l!*:f!*********:f:***X 

DECLARE  ( CHAR, T)  BYTE; 

T=(A=E);  X*  SAVE  TERMINAL  NUMBER  *X 


x*  CONVERT  MATRIX  CODE  TO  ASCII  *x 
B=0;  HL=C ASCI I3+BC; 

CHAR=  ( A=  M(  HL) ) ; 

x*  CHECK  FOR  CAPITALIZATION  *X 
D=0;  HL=  r CAP ITALIZE] +DE: 

IF  (A=M(IIL);  A::0)  JZERO  ( A=CIIAR-6 1H)  PLUS 

S ( A=CHAR-7BH)  MINUS  THEN  X*  CONVERT  TO  *X 
CHAR=( A=CHAR-20H) ; X*  UPPER  CASE  LETTER  *X 

X*  CHECK  FOR  ANY  KEY  COMMANDS  *X 

C=(A=CHAR>;  A=T; 

CALL  KEYSCOMMAND ; 


X*  A REG  RETURNED  TRUE  IF  KEY  CMD  FOUND  *X 
IF  ( A=>>  A)  !CY  THEN  X*  DISPLAY  CHAR  *X 

DO; 

A=T,  CALL  C CnECKSCURSOR) ; 

A=T;  HL=[  CURSOR]; 

CALL  [GETS INDEX];  X*  GET  CURSOR  OFFSET  *x 

CAI.L  [ GET3D I SPLAYS  ADDR]  ; 

M( HL)  = ( A=CHAR) ; 

x*  UPDATE  CURSOR  POSITION  BY  ONE.  BC  VAS*X 
X*  RETURNED  FROM  GETSDISPLAY8ADDR  SET  *X 
X*  TO  THE  VALUE  OF  CURSOR.  *x 

HL=  BC+  1 ; 

A=T;  CALL  [ UPDATE3CURS0R] ; 

END; 

END  TERMS  I NPUTSCNTL; 


EOF 

/******:R******:S********:****:):**:f:**:n**:R****:f::ic**********X 
^*****  TERMINAL  INTERFACE  SYSTEM  FUNCTIONS  *»*w****x 
✓ ****:K:***:fc*****:t:******:.,c*****»:**:?:******:***********:R***X 


[ MACRO  I BUFFS  EMPTY 
[MACRO  MTS8CMDS READY 
[ MACRO  CR 
[MACRO  LF 


’O’  ] 

•OFOH'  ] 
' ODH'  ] 
’OAH’  ] 


/**#****:.>:********:is*:f:**********:*:«:K******:**:f:***:********X 

/*****  INTERNAL  AND  EXTERNAL  LINKAGE  MACROS  *******x 
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[ I NT  GB  TB]  [GB  :=  0]  [TB  : = 1000H1 


[ MACRO 

TASK 

’ M(  [ HEX  GB 

+ 3E90H] ) ’ ] 

[MACRO 

MTSSMESSAGE 

’[HEX 

TB 

+ 

011CH] ’ 

] 

[ MACRO 

SIZEOMESSAGE 

’ [HEX 

TB 

+ 

01CFH] ’ 

] 

[ MACRO 

CURSOR 

’[HEX 

TB 

+ 

01D5H] ’ 

] 

[ MACRO 

CURRENTSLINE 

’ [ HEX 

TB 

+ 

01DDH] ’ 

] 

[ MACRO 

NEXTSCHAR 

’[HEX 

TB 

+ 

0IE5H] ’ 

] 

[ MACRO 

ENDS  I BUFF 

’[HEX 

TB 

01EDH1 ’ 

] 

[MACRO 

COMP ARES PTRS 

’[HEX 

TB 

+ 

0213H] ’ 

] 

[ MACRO 

C0NVERT3NUMBR3T0SASC I I ' 

' [ HEX  TB 

+ 023 1H] 

[MACRO 

GETS  INDEX 

’[HEX 

TB 

+ 

024CH] ’ 

] 

[ MACRO 

GETSVALUE 

’[HEX 

T3 

+ 

0259HJ ’ 

] 

[ MACRO 

STORES VALUE 

’[HEX 

TB 

+ 

0262H] ’ 

J 

[ MACRO 

MOVES BYTES 

’[HEX 

TB 

+ 

026 BH] ’ 

] 

[ MACRO 

SWAPSCURSOR 

’[HEX 

TB 

+ 

027EH] ’ 

] 

] 


C MACRO  BLANK3D ISPLAY  ’ C IIEX  TB  + 02A3H]  • ] 

[ MACRO  CHECKSCURSOR  ’ C HEX  TB  + 02D0H]  ’ ] 

[MACRO  GET3DISPLAY3ADDR  ’[HEX  TB  + 02B7U] ’ ] 
[ MACRO  GETSSTATUS3ADDR  ’ [ HEX  TB  + 02ECH] ’ ] 
[MACRO  GETOTERN3STATUS  ’[HEX  TB  + 02F9HJ  ’ ] 
[ MACRO  UPDATESCURSOR  ’ [ HEX  TB  + 03C2H] ’ ] 


BL I NKSCURSORS : PROCEDURE; 

//;S:K***:(:*:X:fc:fc:K:fc:l:**:K:S*:f:*S**«*:t::ii::**:t:****:K*************:!:***/' 

/-*  SWAPS  T1IE  CURRENT  CONTENTS  OF  CURSORC  I ) WITH 
/*  SWAPS POS( I ) FOR  EACH  TERMINAL  (1=0  TO  3).  */ 

/*  CALLED  BY:  TIMER5HDLR  ( INTERRUPT  MOD)  */ 

Z***:***:*:^************:..*****************************.*/' 

DECLARE  I BYTE: 

I=( A=3) : 


REPEAT; 

HL= [ CURSOR] ; 

CALL  [GETS  INDEX]; 

CALL  [GETSDISPLAYSADDR] ; 
A= I ; CALL  [ SWAPSCURSORJ ; 


I=(A=  I-I)  ; 


UNTIL  CA::»)  MINUS: 
END  BL I NKSCURSORS; 


CLEARSSTATUSSLINE:  PROCEDURE: 
/********:*:***********:**********:!:*****:!:***************/’ 
/*  CLEARS  THE  STATUS  LINE  OF  THE  SPECIFIED  TERMINAL.*/' 
/*  INPUT:  A - TERMINAL  NUMBER  */ 

/*  CALLED  BY:  MTSSIPL  (MONITOR  MOD);  */ 

/■*  «UIT  (SERVICE  MOD); 

/*************»:**************************************/ 
CALL  [ GETSSTATUS8ADDR] ; 

BC=0;  DE=64;  /*  SETUP  PARAMETERS  FOR  */ 

CALL  [ BLANKSDISPLAY] ; /*  BLANK8DISPLAY  PROC  */ 

END  CLEARSSTATUSSLINE; 


MTSSMSG:  PROCEDURE; 

//****************************************************/' 


./*  CONTROLS  THE  MTS  MESSAGE  DISPLAY  FIELD  ON  THE 
/*  STATUS  LINE  OF  THE  TERMINAL  SPECIFIED  BY  ’TASK’.  */ 
/■*  THE  MTS  MESSAGE  FIELD  STARTS  AT  POSITION  43  AND  */ 
/*  UTILIZES  TIIE  REMAINING  16  BYTES  FOR  MTS  MESSAGES  */ 
/*  ( SEE  MTSSMESSACE  DATA)  . *S 

/*  INPUT:  E - MTS  MESSAGE  NUMBER.  */ 

CALLED  BY;  MTS  (SERVICE  MOD);  */” 

/*  MINI8DISK  (MONITOR  MOD);  */ 

/*  RECOVER  ( MONITOR  MOD)  ; *■/ 

/*  3UMPSTASK  (MONITOR  MOD);  */ 


/a************************************:!:**************/ 
DECLARE  MSGNO  BYTE; 
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MSGNO=  ( A=E) i 
A=  [ TASK] i 

CALL  C GETSSTATUSSADDR]  5 

BC=48:  /*  MTS  MSG  FIELD  OFFSET  FROM*/ 

/*  STATUS  EASE  ADDRESS  */ 


A=  NSGNO ; E=4;  CY=0; 

REPEAT!  /*  COMPUTE  OFFSET  INTO  THE 

A=<  < A;  /*  PITS  STIES  SAGE  DATA  VECTOR 

UNTIL  ( E=E- 1 ) ZERO; 


DE=(HL=IIL+BC)  ; /*  SETUP  PARAMETERS  FOR 

B=0;  C*A;  /*  [MOVESBYTES]  PROC 

HL=  C MTS8MESSAGE] +BC •, 

BCS 16 i CALL  [ MOVES BYTES] s /*  DISPLAY  MSG 

END  MTSSMSC; 


■*■/ 

*/ 

■*/ 

*/ 


SIZE8MSC:  PROCEDURE; 

/***#*****:(:  ******************************************/ 
/*  CONTROLS  THE  DISPLAY  OF  THE  CURRENT  MEMORY  SIZE  */ 
/%  ON  THE  STATUS  LINE  CF  THE  TERMINAL  SPECIFIED  BY  */ 
/*  •TASK*.  THE  SIZE  MESSAGE  STARTS  AT  POSITION  40  */ 


/*  AND  HAS  THE  GENERAL  FORMAT:  */ 

/*  40  47  */ 

/*  */ 

/*  NRK  MTS  E.C.  I6K  MTS  */ 

/*  */ 

/%  WHERE  */ 

sx  " NR"  IS  THE  CURP-ENT  MEMORY  SWAP  SIZE  */ 

/*  ALLOCATED  TO  TRAT  TERMINAL  USER.  */ 

THE  RANGE  IS  FROM  0 TO  40K.  THE  INPUT  MEMORY  »/ 

/*  SIZE  NUMBER  IS  CONYERTF.D  TO  ASCII  FOR  DISPLAY.  */ 

/*  INPUT:  A - MEP10RY  SIZE  */ 

/*  CALLED  BY:  SIZE  (SERVICE  MOD);  */ 

/*  LOGIN  (SERVICE  MOD);  */ 


DECLARE  MF.MSSIZE  BYTE; 

MEMOS IZE=  A; 

A=  l TASK] ; 

CALL  I GETSSTATUSSADDR] ; 

BC=  40 ; /*  SIZE  MSG  FIELD  OFFSET  */ 

HL=  HuL+BC ; /*  HL= START INC  ADDRESS  OF  */ 

/■*  SIZE  MSG  FIELD  ON  STATUS  */ 
S*  LINE.  */ 

A=  MEMSSIZE; 

CALL  [ C0NVERTSNUMBRST03ASC III; 

M(HL)  = (A=B);  HL=  HL+ 1 ; /'*■  DISPLAY  MEMORY  SIZE  */ 

M(HL)  = (A=C);  DE=  HL+ 1 ; /*  SETUP  PARAMETERS  */ 

HL= [ S IZESMESSAGE] ; /*  FOR  [ MOVESBYTES]  PROC*/ 

BC=6 ; CALL  l MOVESBYTES] ; /*  DISPLAY  REST  OF  */ 

/*  SIZE  MESSAGE  */ 

END  SIZEOMSG; 


STATUS8MSG:  PROCEDURE; 

/#********************#*******#***********:(:******:)::*#*/ 
/*  CONTROLS  THE  STATUS  DISPLAY,  POSITIONS  0 THRU  39  */ 


/*  OF  THE  TERMINAL  STATUS  LINE.  IT  HAS  THE  */ 

/*  FOLLOWING  GENERAL  FORMAT:  */ 

/*  0 39  */ 

/*  */ 

/*  A=N0rB=N0rC=N0rD=N0rE=N0rF=N0rG=N0rH=N0r  */ 

/*  

/■*  WHERE  */ 

/*  THE  LETTER  ON  THE  LEFT  OF  THE  EQUAL  SIGN  */ 

/*  SPECIFIES  THE  DRIVE.  */ 

/%  ’NO’  IS  THE  DISK  NUMBER  (0-31).  */ 

/*  ' r 1 IS  AN  OPTIONAL  PARAMETER  WHICH  IS  */ 

/*  DISPLAYED  WHEN  THE  ATTACHED  DISK  IS  A */ 

/*  RESTRICTED  (r)  READ  ONLY  DISK.  */ 

/*  THE  TERMINAL  IS  SPECIFIED  BY  ’TASK’.  */ 

/*  INPUT:  A - ASCII  CODF,  FOR  RESTRICT  (r).  */ 

/*  OR  BLANK  (SPACE).  */ 
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z'* 

B - DRIVE  NUMBER  (MUST  BE  CONVERTED  TO 

/* 

A LETTER 

FOR  DISPLAY). 

*/ 

/* 

C - DISK  NUMBER  (RANGE  0-31;  MUST  BE 

*/ 

/% 

CONVERTED 

TO  ASCII  FOR  DISPLAY). 

*/ 

/* 

CALLED  BY:  LOGIN 

(SERVICE  MOD); 

*/ 

/% 

ATTACH 

(SERVICE  MOD); 

*/ 

/****************************************************/ 
DECLARE  ( RESTRICT, DRIVESLTR, DISKSNR)  BYTE; 

/*  GET  INPUT  PARAMETERS  */ 
RESTRICT1 A i DR I VE3LTR= ( A=  B) ; DISKSNR= ( A=C) i 
A=  C TASK! ; CALL  C GETSSTATUSSADDR] ; 

/*  COMPUTE  THE  APPROPRIATE  STATUS  */ 
/*  BASE  OFFSET  TO  DETERMINE  WHERE  */ 
/*  TO  DISPLAY  THIS  STATUS  INFO  */ 

C=0;  B=  ( A=DRI VESLTR) ; 

DO  WHILE  (A::0)  tZERO; 

C= ( A=C+3) j 
B=  ( A=  B-  1 ) i 
ENDj 

IIL=HL+BC ; /*  SETUP  ADDRESS  FOR  STATUS  MSG.  */ 

/*  DISPLAY  DRIVE  LETTER  */ 

M(HL>=( A=DRIVESLTR+41H) ; 

HL= HL+ 1 ; 

/*  DISPLAY  EQUAL  SIGN  */ 

M(  HL)  = ( A=  * = * ) i 
HL=  HL+ 1 ; A’DISKSNR; 

/«  CONVERT  AND  DISPLAY  DISK  NUMBER  */ 
CALL  C CON VERTS NUMB R3T03ASC 113; 

M( HL)  = ( A=B) i HL=  HL+ 1 ; 

M( HL) = ( A=C> j HL=HL+1; 

/*  DISPLAY  RESTRICT  OR  BLANK  3YTE  */ 
M(HL)=(A= RESTRICT) ; 

END  STATUSSMSG; 


TERMI NALSSTATUS : PROCEDURE; 

/*  PROVIDES  THE  INTERFACE  POINT  FOR  OTHER  MTS  SYSTEM*/' 


/»  FUNCTIONS.  RETRIEVES  THE  CURRENT  TERMINAL  STATUS  */ 
/*  FOR  THE  TERMINAL  SPECIFIED  BY  ’TASK'.  */ 
/*  OUTPUT:  A - SET  TO  THE  TERMINAL  STATUS  (EITHER  */ 
/*  INPUT8WAITING;  MTS3CMD9READY ; OR  */ 
/*  I BUFF8EMPTY)  BY  GET8TERM3ST ATUS  PROC.*/ 
/*  CALLED  BY:  WRITE3TERMINAL;  MTS(SERVICE  MOD);  */ 
/*  READSTERMINAL;  */ 
/*  MTSSIPL  (MONITOR  MOD);  */ 


/***************:!:**:):•*********************************/ 
A=  I TASK] ; 

CALL  CGETSTERMSSTATUS] ; 

END  TERM I NALSSTATUS; 


READSTERMINAL:  PROCEDURE; 

/*********:)::***********:*******************************/' 
/*  GETS  THE  NEXT  CHAR  FROM  THE  TERMINAL  INPUT  BUFFER*/' 
/*  SPECIFIED  BY  * TASK’ . */ 

/*  IT  IS  ASSUMED  THAT  THE  CALLING  PROCEDURE  HAS  */ 

/*  CHECKED  TERMINAL  STATUS  TO  ENSURE  INPUT  IS  */ 

/*  WAITING  PRIOR  TO  CALLING  READSTERMINAL.  */ 

/*  A TEST  FOR  END  OF  I BUFF  IS  MADE  AND  IF  SO,  A */ 
/*  ’CR’  CHAR  IS  RETURNED;  THE  TERMINAL  STATUS  IS  SET*./ 
/*  TO  EMPTY;  AND  THE  NEXT8CHAR  PTR  IS  SET  TO  CURRENT*/ 
/*  LINE.  *' 

/*  IF  NOT  AT  END  OF  I BUFF,  THE  NEXT  CHAR  IS  RETURNED*/ 
/*  AND  THE  NEXT3CHAR  PTR  INCREMENTED.  */ 

/*  OUTPUT:  A - CHAR  OR  CR  */ 

/*  CALLED  BY:  MTS  (SERVICE  MOD);  MTSSIPL  (MONITOR);*/ 

/*  MONITOR  (MONITOR  MOD);  */ 

/****************************************«***********/ 

DECLARE  CHAR  BYTE; 

DECLARE  PTR(  2)  BYTE; 
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A=  C TASK] i HL=  I NEXTSCHAR] ; 

CALL  ICET* INDEX];  /*  DE=  ADDR  OF  NEXT*CHAR  PTR  */ 
HL=  t ENDS IBUFF] +BC; HL= ADDR  OF  ENDS  I BUFF  PTR  x/ 
CALL  I COMPARESFTRS ] ; NEXTSCHAR- END3 IBUFF  ??  xs 
IF  ( A=  > > A)  CY  THEN 

DO;  /*  AT  END  OF  IBUFF,  SET  xy 

/*  NEXTSCHAR  = CURRENTSLINE  */ 
A=  t TASK] ; HL= I CURRENT3L I NE ] ; 

CALL  CGET9 INDEX]; 

BC= ( HL= t NEXTSCHAR] +BC) ; 

CALL  [ GETSVALUE] ; /*  HL= CURRENTSLINE  VALUED 


De= BC+  1 * 

CALL  C 9TORES VALUE] ; 

/*  UPDATE  TERMINAL  STATUS 
CALL  TLRMINALSSTATUS;  /*  RETURNS  IIL=  ADDR 

/*  OF  TERN3STATUS . 
M(HL)=(A=  [ IBUFFSEMPTYJ ) ; 

/*  RETURN  ’CR’  TO  CALLER 
CIL4R=  ( A=  [ CR]  ) ; 

END 

ELSE  s*  ROT  AT  END  OF  IBUFF 

RETURN  THE  CHAR 

DO; 

A= t TASK] ; HL= C NEXTSCHAR] ; 

CALL  [GETS INDEX];  /»  GET  AND  SAVE 
PTR=HL;  NEXTSCHAR  OFFSET 

CALL  [ GETOD I SPLAYS ADDR]  ; 

CHAR=(A=M(HL)>  ; RETURN  CIIAR 

s*  INCREMENT  NEXTSCHAR 
DE=  ( HL=  PTR+  1 ) ; /'*  SETUP  t ST0RE8 VALUE ] 

HL= BC+ I ; ✓*  PARAMETERS 

CALL  C STORES VALUE] ; 

END; 


xy 

xy 

xy 


xy 


xy 

xy 


xy 

xy 


xy 


xy 

xy 

xy 


A=CHAR;  /*  RETURN  APPROPRIATE  RESPONSE  *✓ 

END  READSTERMINAL; 


WRITE# TERMINAL:  PROCEDURE; 

/**********:i!*:it***x***:s****:<::ii:************:i::t:*:t::i:**:>‘:***:»:*x 


y*  DISPLAYS  THE  CHAR  AT  THE  CURRENT  CURSOR  POSITION  xy 
yx  OF  THE  TERMINAL  SPECIFIED  BY  ’TASK*.  IT  CHECKS  */ 
yx  FOR  TWO  SPECIAL  CHARACTERS  WHICH  AFFECT  THE  *' 
/*  DISPLAY  CURSOR  POSITION.  xy 
/*  ’CR’  RETURNS  THE  CURSOR  TO  THE  BEGINNING  OF  THE  *✓ 
/x  CURRENT  DISPLAY  LINE.  ’LF’  MOVES  TEE  CURSOR  DOWN  x/ 
/x  TO  THE  NEXT  LINE.  xy 
yx  FOR  ALL  OTHER  CHARACTERS,  THE  CHAR  IS  DISPLAYED  xy 
/x  AND  THE  CURSOR  POSITION  INCREMENTED.  xy 
/x  PRIOR  TO  OUTPUT,  THE  CURRENT  CURSOR  DISPLAY  X/ 
/x  ADDRESS  IS  CHECKED  TO  ENSURE  THAT  THE  CURSOR  CHAR*/' 
/*  IS  SAVED.  OUTPUT  OF  CHARACTERS  IS  DONE  UNDER  *✓ 
/x  INTERRUPT  LOCKOUT  TO  ENSURE  THAT  SWAPPING  BY  x/ 
yx  BL.MMCURSORS  PROC  IS  NOT  DONE.  xy 
/x  SUBPKOCEDURE:  UPDATE8PTRS ; */ 
/x  INPUT:  E - ASCII  CODE  OF  CHAR  TO  BE  DISPLAYED  X/ 
/x  CALLED  BY:  MTS  (SERVICE  MOD);  x/ 
/X  MTSaiPL  (MONITOR  MOD) ; */ 


/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/ 

DECLARE  CHAR  BYTE; 

DECLARE  SAVE8CURSOR  (2)  BYTE; 

UPDATE3PTRS:  PROCEDURE: 

,/*x**X**Xsf:X*****x:*X:*****x*********X:**X*****:S*****/' 

/X  AFTER  THE  DISPLAY  OF  EACH  CHAR  THE  CURRENT  X/ 
/x  LINE  PTR  AND  NEXT  CHAR  PTR  ARE  ALWAYS  SET  TO  */ 
/x  NEW  CURSOR  POSITION.  ADDITIONALLY,  THE  x/ 

/x  TERMINAL'S  STATUS  IS  SET  TO  IBUFF  EMPTY.  xy 

yxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxy 
yx  GET  CURSOR  POSITION  xy 

\=  C TASK]  ; HL=  [ CURSOR]  : 

CALL  [GET# INDEX); 
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/*  SET  CURRENTSL I NE  = CURSOR  */ 

BC=  ( HL=  C CURRENTSL I NEJ  +BC) s 

CALL  C GETS VALUE! i /*  HL=  CURSOR  VALUE  */ 

DE=  BC+  1 1 

CALL  [ STORESVALUE] ; /*  CURRENTSL  I NE=  CURSOR  */ 
SAVESCURSOR’ HL  ; 

/*  SET  NEXTSCHAR  = CURSOR  */ 

A= C TASK] i HL= C NEXTSCHAR] ; 

CALL  [CET3 INDEX]; 

HL=  SAVESCURSOR ; I>E=  DE+  1 ; 

CALL  ! STORES VALUE] ; NEXTSCHAR’ CURSOR  */ 

/*  SET  TERMINAL  STATUS  = EMPTY 
CALL  TERMI NALSSTATUS ; 

M( HL) » ( A’  [ I BUTFSEMPTY] ) ; 

END  UPDATE8PTRS; 

/*******************************************:!:/ 
/*  START  OF  WRITESTERMINAL  PROCESSING  */ 

/****#****:K*************:S:»:****y::.,:*:**#****:*:fc***/' 


DISABLE; 

CHAR=(  A=E)  ; 

A*  C TASK] ; CALL  ! CHECKSCURSOR] ; 

A=  C TASK]  ; IIL=  [ CURSOR]  ; 

CALL  ECET3 INDEX]; 

IF  C A*CHAR-CCR] ) ZERO  THEN 
DO; 

CALL  I GET3 VALUE] ; 

L= ( A= L OCOH) ; /* 

END 

ELSE 

DO; 

IF  <A=CHAR-  ILF])  ZERO 
DO; 

CALL  t GETSVALUE] ; 

BC*  64 ; HL=HL+BC; 

END 

ELSE 

DO; 

SAVE3CURS0R=HL: 

CALL  [ GET9DISPLAYSADDR] ; 

M(  HL)  = ( A=  CHAR) : 

DE=  ( HL= SAVESCURSOR) ; 

CALL  [GETSVALUE]; 

HL’HL+1;  s*  INCREMENT  CURSOR  */' 

END; 

END: 

/*  HL  REG  HOLDS  NEW  CURSOR  POSITION  */ 
A= t TASK ; CALL  C UPDATESCURSOR] ; 

ENABLE; 

/*  UPDATE  OTHER  DISPLAY  PTRS  */ 

CALL  UPDATESPTRS; 

END  WRITESTERMINAL; 


/*  CARRIAGE  RETURN  */ 


/*  HL= CURSOR  */ 

GET  LEFT  MARGIN  */ 


THEN 

/*  LINE  FEED  */ 

s*  HL= CURSOR  ■*/ 

/*  DISPLAY  CHAR  */ 


/***************a“**************************************/' 
/*****  MTS  COMMAND  PROCESSOR  ( MCP)  * * * */ 

/***#***********#***:t:***:|:******#*:S:******:f:**************/ 

19FAH: 

MCP:  PROCEDURE: 


/-at************************:*:  ****************************/' 

/*  MCP  IS  AN  INDEPENDENT  MODULE  OF  THE  MICROCOMPUTER 
TIMESHARED  SYSTEM  (MTS)  DEVELOPED  FOR  THE  NPS 
MICROCOMPUTER  LABORATORY  SYCOR  440  SYSTEM. 

THIS  MODULE  IS  CALLED  BY  THE  MTS  MONITOR  TO 
PROCESS  ANY  SYSTEM  COMMANDS  ENTERED  THROUGH  THE 
TERMINAL  INTERFACE  BY  THE  USER.  MTS  COMMANDS  ARE 
VALIDATED  BY  MCP  AND  THEN  SENT  TO  MTS  SERVICE 
CALL  CONTROL  MODULE  FOR  FURTHER  PROCESSING. 

MCP  IS  WRITTEN  IN  PLM  FOR  TWO  REASONS: 

(1)  TO  UTILITZE  A HIGH-LEVEL  LANGUAGE  TO 
FACILITATE  THE  DESIGN  AND  DEBUGGING  TASK 
DURINC  THE  DEVELOPMENT  OF  MCP. 

(2)  TO  PROVIDE  A PLM  PROGRAM  WHICH  ILLUSTRATES 
THE  FUNCTION  CALL  REQUIREMENTS 

FOR  ANY  USER  PROGRAM  TO  INTERFACE  WITH  MTS. 

THERE  ARE  TWO  PRIMARY  DIFFERENCES  BETWEEN  THE  MCP 
INTERFACE  WITH  NTS  AND  A USER  PROGRAM/ MTS  INTERFACE. 

(1)  ONE  IS  THE  ENTRY  PORT.  THE  MTS  INTERFACE  PORT 
FOR  USER  PROGRAMS  IS  2000n.  THE  ENTRY  PORT 
FOR  MCP  IS  1FO0H. 

(2)  THE  OTHER  DIFFERENCE  IS  THAT  USER  PROGRAMS 
DO  NOT  HAVE  TO  BE  CONCERNED  WITH  SAVING 
AND  RESTORING  THE  MTS  MONITOR  STACKFTR. 


MCP  WILL  PROCESS  THE  FOLLOWING  SYSTEM  COMMANDS 
ENTERED  AT  THE  TERMINAL  BY  THE  USER: 

COMMAND  PARAMETERS 


LOGIN 

QUIT 

ATTACH 

PROTECT 

RESTRICT 

UNPROTECT 

SIZE 


< DISK  NUMBER)  /<  KEY) 

NONE 

< DRIVE  LETTER)  < DISK  NUMBER)  /< KEY) 

< DISK  NUMBER)  ✓< KEY) 

< DISK  NUMBER)  /< KEY) 

< DISK  NUMBER)  /< KEY) 

< MEMORY  SIZE) 


WHERE 

< DRIVE  LETTER) - 


< DISK  NUMBER)  - 

< DISK  NUMBER)  - 
/< KEY) 

< MEMORY  SIZE)  - 


DESIGNATES  A VIRTUAL  FLOPPY  DISK 
DRIVE  TO  BE  ONE  OF  THE  LETTERS 
A THRU  H. 

SPECIFIES  A VIRTUAL  FLOPPY  DISK 
NUMBER  FROM  0-31. 

SPECIFIES  A DISK  NUMBER  FROM  0-31. 
SPECIFIES  A 4 CHARACTER  KEY  CODE. 
SPECIFIES  THE  SIZE  OF  THE  USER 
PROGRAM  AREA. 


/***************************:(:****#**#****************:*#/ 


/at:*****:**:**!****!*****:******:!:  is*******:)'*****:**********:*****/' 

/*  * * * MCP  LITERAL  AND  DATA  DECLARATIONS  * * */ 

/w*************************************** ****** ********/ 


/*****  MCP  LITERAL  DECLARATIONS  *****/ 
DECLARE 

LIT  LITERALLY  ’LITERALLY’. 

JTTS  LIT  ’ 1FOOH’ , INTERNAL  MTS  PORT  */ 
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MTSSCMD3 READY  LIT  ’OFOH’ 

INVALIDSCND  LIT  ’ 1 ’ 

TRUE  LIT  * OFFH’ 

FALSE  LIT  ’O' 

CR  LIT  * ODH’ 

LF  LIT  'OAH' 

TAB  LIT  ’9’ 

MAXSCBUFFSS I ZE  LIT  ’64’ 


READS MTSSCMD  LIT  ’-1’ 

ATTACH  LIT  ’O’ 

MTSSMSG  LIT  ’1* 

LOGIN  LIT  ’2’ 

PROTECT  LIT  ’3’ 

QUIT  LIT  ’4’ 

RESTRICT  LIT  ’5’ 

SIZE  LIT  ’6’ 

UNPROTECT  LIT  *7’ 

TERM I NALSSTATUS  LIT  '8' 

READ3TERMINAL  LIT  '9' 

WRITES/TERMINAL  LIT  ’10’ 


, /*  INTERNAL  MTS  CMD  */ 

/*MTS  SYSTEM  CMD  NUMBERS*/' 


/* 


* * f!CP  GLOBAL  DECLARATIONS 


*/ 


DECLARE 

CBUFF  (64) 

CBUFF5LENGTH 

CBUEFSPTR 


BYTE.  /*  CMD  BUFF  FOR  NTS  COMMAND  */ 
BYTE,  /*  NUMBER  OF  CHARS  IN  CBUFF  */ 
BYTEs  /*  PTS  TO  NEXT  CHAR  IN  CBUFF 

TO  BE  PROCESSED  */ 


DECLARE 

CHAR 

VALUE  (2) 


BYTE,  /*  USED  FOR  CHAR  MANIPULATION  */ 
BYTE,  /*  VECTOR  FOR  CONVERTING  NUMBERS  */ 


PARAMETERS! 6)  BYTE;  /'^PARAMETERS  FOR  MTS  SYSTEM  CALLS*/ 


/******************:■•***********************************/ 
/#****  fTTS  INTERFACE  PROCEDURES  *****/ 

/%*if^*^.-4:*il:^-**-K*\t:U'»****>e****'**--K****'Jf******»*x*****t-***.*/ 


//«*«*«*»«»*«***««■«  4c*»»**«*«ac*»4c»*********************/ 
/*  MTS  1-  PROVIDES  MTS  INTERFACE  FOR  FUNCTIONS 
WHICH  DO  NOT  REQUIRE  A RETURN  VALUE. 

•F’  CONTAINS  THE  MTS  CMD  NUMBER;  ’A’  CONTAINS 
THE  PARAMETER  OR  ADDRESS  TO  LIST  OF  PARAMETERS. 
CALLED  BY:  ERRORSMSG;  SEND3MTSSCMD 

*/ 

MTSl:  PROCEDURE  <F. A) ; 

DECLARE  F BYTE,  A ADDRESS; 

GO  TO  MTS; 

END  MTS  I ; 

✓'*************»*:.’:************:•:*******:):**************/ 
/*  MTS2-  PROVIDES  MTS  INTERFACE  FOR  FUNCTIONS 
WHICH  REQUIRE  A RETURNED  VALUE. 

’F’  AND  ’A’  ARE  THE  SAME  AS  IN  MTSl. 

CALLED  BY:  READSCHAR;  «END*MTS8CMD 

*/ 

MTS2 : PROCEDURE  < F , A)  FYTE; 

DECLARE  F BYTE,  A ADDRESS; 

GO  TO  MTS; 

END  MTS2; 


/******************************************************/ 
/*  * * * * * MCP  PRIMITIVE  PROCEDURES  * * * */ 

/*****************«************************************/ 


READSCHAR:  PROCEDURE  BYTE; 
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RETURN  !TrS2< HEADSMTSSCMD,  0) 
END  READSCHAR; 


CBUFFSNOTSEMPTY:  PROCEDURE  BYTE; 

RETURN  CBUFFSPTR  < CBUFF8LENGTJI; 
END  CBUFFSNOTSEMPTY; 


DEBLANK:  PROCEDURE; 

DO  WHILE  (CBUFFSPTR  < CBUFFSLENGTH)  AND 
(CBUFF( CBUFFSPTR)  = ’ ’ ) OR 
(CBUFF( CBUFFSPTR)  = TAB); 
CBUFFSPTR  ■ CBUFFSPTR  + X; 

END; 

END  DEBLANK; 


ERRORS MSG:  PROCEDURE; 

CALL  MTS  1 ( MTS3NSG , INVAL I DSCMD) : 
COTO  FINI; 

END  ERR0R3MSG; 


/**S**********:!:***:f:**X:K*X***  ********:***#*************/ 

/*  FILLSCBUFF  - CHECK  CURRENT  TERMINAL  STATUS  FOR 
MTS  COMMAND.  IF  NOT,  EXIT;  OTHERWISE  FILL  THE 
COMMAND  BUFFER  WITH  THE  MTS  COMMAND. 

CALLED  BY:  HCP  MAIN  CONTROL 

*/• 

FILLSCBUFF:  PROCEDURE; 

IF  HTS2*. TERMI N ALSSTATUS , 0)  = MTS3CMD3 READY  THEN 
DO; 

CBUFFSPTR,  CBUFFSLENGTH  = 0; 

DO  WHILE  (CBUFFSLENGTH  < = MAXSCBUFFSS IZE)  AND 

( ( CBUFF( CBUFFSLENGTH) := READSCHAR) < >CR) ; 
CBUFFSLENGTH  = C3UTFSLENGTH+ I ; 

END; 

END; 

END  FILLSCBUFF; 


INITIALIZE:  PROCEDURE; 

DECLARE  I BYTE; 

BO  1=0  TO  5; 

PARAMETERS! I ) = 0FFH; 
END; 

VALUE( 0) , VALUE! 1)  = 0; 
END  INITIALIZE; 


✓ SMC****************:*******;*:**;**************!**********/' 
*/ 

LETTER:  PROCEDURE  (C)  BYTE; 

DECLARE  C BYTE; 

RETURN  C >=  ’A’  AND  C <=  ’Z’; 

END  LETTER; 


✓S£*****:f:**********:):*:*:l:***********:!::):*:*::*  *******:(:**#:(:**/ 

/■*■  NUMBER  - RETURN  TRUE  IF  'C'  IS  A NUMBER. 

CALLED  BY:  GETS NUMBER;  GETS PARAMETERS ; 

ATTACH8CMD;  SIZESCMD 

NUMBER:  PROCEDURE  (C)  BYTE; 

DECLARE  C BYTE; 

RETURN  G > = 'O’  AND  C < = ' 9 ’ ; 

END  NUMBER; 


/***********:S*:::***:XX******:!i:*****:f::M:*******:):*****xx***/ 

/*  READSCMDSL I NE  - READS  CHAR  FROM  COMMAND  BUFFER; 
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CONVERTS  LETTERS  FROM  LOWER  TO  UPPER  CASE, 

IF  REQUIRED. 

CALLED  BY:  GETSKEY;  CET8NUMBEH;  GET3PARAMETERS ; 

ATTACHSCMD;  S IZE3CMD;  MCP  MAIN  CONTROL 
READSCMDSLINE:  PROCEDURE  BYTE: 

DECLARE  C BYTE: 

IF  C C:  =CBUFF(  CEUFFSPTR)  ) >=  6111  /3c  LOVER  CASE  A */ 
AND  C <=  7 AH  THEN  /*  LOWER  CASE  Z */ 

C = C AND  5FH;  /*  CONVERT  TO  UPPER  CASE  */ 
CBUFF3PTR  ■ CBUFFSPTR+ 1 ; 

RETURN  C; 

END  READ3CMDSLINE; 


/’*Z#X%X*%X:i:***X*$X*X**X*X****X*****##XX*#*##X##******/ 
/*  SCAN3T03BLANK  - SCAN  TO  NEXT  BLANK  OR  TAB  CHAR. 
CALLED  BY:  MCP  MAIN  CONTROL 

3c/ 

SCAN8T0S BLANK:  PROCEDURE: 

DO  WHILE  ( CBUFFSPTR<  CBUFFSLENGTH)  AND 
(CBUFF! CBUFFSPTR) < > ’ •)  AND 

( CBUFFC CBUFFSPTR) < > TAB) ; 

CBUFFSPTR  = CBUFFSPTR+1; 

END; 

END  SCAN3T03BLANK; 


/3c*3c3c3:3:3c3:3!3:*3:3:3:3:3c:):3:3::l:3:3C3:3:3:3::;:3:3:3c3:3:3:3:3c3:3c3:*3:3:3c3:3:3:#3:3:3i:3:3:3:/ 

/*  SENDS MTSSCMD  - ’CMD’  CONTAINS  THE  MTS  CMD  NUMBER 
AND  ’ PARAMETER’  CONTAINS  THE  ACTUAL  PARAMETER 
OR  THE  ADDRESS  OF  THE  ACTUAL  PARAMETER  LIST. 

TWO  MTS  SYSTEM  CALLS  ARE  MADE: 

(1)  MTS2  - PROCESS  SYSTEM  CMD,  WHICH  RETURNS 

A RESPONSE. 

(2)  MTS1  - DISPLAY  RESPONSE  AT  USER  TERMINAL. 

*/ 

SENDS MTSSCMD : PROCEDURE  ( CMD. PARAMETER)  : 

DECLARE  CMD  BYTE,  PARAMETER  ADDRESS; 

CALL  MTS  1 ( MTSSMSG , MTS2  ( CMD . PARAMETER) ) : 

END  SENDSMTSSCMD ; 


/*******»*****:)::):****:**  ******3:********:):****:):************/ 
/*  * 3c  3:  3:  UTILITY  PROCEDURES  3:  3c  * * * * */ 

/3c3c3:3:3c3:3c3c3c3c3:3c3:3:3:3c3c3:3:3c3::<c3c3:3:*c3c3c3:3:3:3:3:3:3:3c3c3c3c3c3c3c3:3:3:3c3c3c3c3c3c3c3:*/ 


/3:3C3:3C3:3C3:3C3C3C3C3C3C3C3C3:3C3C3C3C3C3C313C3C3C3C3C3C3C3C3C3C3C3C3C3C3C3:3C3C3C3C3:3C3C3:3!3C3C3C*/ 

/*  CON  VERTS  VALUE  - CONVERT  ASCII  CODE  IN  ’VALUE’ 

TO  APPROPRIATE  BINARY  VALUE.  THE  RANGE  OF  VALUES 
TO  BE  CONVERTED  ARE  FROM  0-31. 

CALLED  BY:  GETSNUMBER; 

%/ 

CONVERTS VALUE : PROCEDURE  BYTE: 

IF  VALUE!  1 ) = 0 THEN  /3cONLY  A SINCLE  DIGIT  TO  CONVERTS:/ 
RETURN  VALUE!  0 ) -3011 ; 

ELSE  /*  TWO  DIGITS  TO  CONVERT  */ 

RETURN  ( C.ALUE! 0>-39H>* 10+ (VALUE! 1)-30H) ) s 
END  CONVERTS VALUE; 


/•#*c*V***».3t»3c**3c*3C3C**!*************3t3:**3:*****3c*3t***3C3t**r 

/3c  GETSKEY  - GET  THE  < KEY>  PARAMETER.  IF  ENTERED; 
STORE  KEY  IN  THE  PARAMETER  LIST  STARTING  AT  I. 
CALLED  BY:  ATTACHSCMD;  GETSPARAMETERS; 

•*■/ 

GETSKEY:  PROCEDURE  (I): 

DECLARE  I BYTE; 

IF  CBUFF3N0T3EHPTY  THEN  /*NEXT  CHAR  MUST  BE  ’/’  */ 

DO; 

IF  ( CHAR: = READ8CMD9L I NE)  = ’/’  THEN 

DO  WHILE  ( I<  6)  AND  CBUFF8N0T3 EMPTY: 
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PARAMETERS ( I ) = READSCMDSL I NE ; 
1=1+1; 


END; 

ELSE  /*  IS  USED  TO  INDICATE  */ 

CALL  ERRORS MSG;  /*  < KEY>  AND  IS  REQUIRED.  */ 

END; 

END  GETS KEY; 


/*****xx**x************~**x**--***-M.'z\r-***'Z**x****. k*#***/ 
/*  GETSNUMBER  - GET  <DISK  NUMBER>  PARAMETER  AND 
CONVERT  IT  FROM  .ASCII  TO  DINARY.  STORE  THE 
RESULT  IN  PARAMETER  LIST  AT  ’I’.  UPON  ENTRY, 

’CHAR'  HOLDS  THE  FIRST  D1CIT. 

CALLED  BY:  ATTACHSCND;  GETS PARA METERS ; 

■*/ 

GETSNUMBER:  PROCEDURE  (I); 

DECLARE  I BYTE; 

VALUE! 0)  = CHAR; 

IF  CBUFFSNOTSEMPTY  AND 

NUMBER! CHAR: =READ3CMDSLINE) 

THEN  /*  TWO  DIGIT  DISK  NUMEER  */ 

VALUE! 1 ) = CHAR; 

PARAMETERS!  I)  = CONVERTS  VALUE ; 

END  GETSNUMBER; 


/^**:|t;*:K*:**:r.******:t'.**=r.****:K5K***'.«***:S********:******:  ***»*/• 

/*  CETSPARAMETERS  - USED  TO  GET  THE  <DISK  NUMBER> 

AND  <KEY>  PARAMETERS.  GENERATES  ERROR  MSG  IF 
NEXT  CHAR  IS  NOT  A NUMEER. 

CALLED  BY:  LOGINSCMD;  GET3REQU I RED3PARAMETERS : 

GET3PARAMETERS:  PROCEDURE: 

IF  NUMBER!  CHAR: =READSC?©CL I NE)  THEN 
DO; 

CALL  GETSNUMBER! 0) ; 

CALL  DEBLANK; 

CALL  GETSKEY!  I ) ; 

END; 

ELSE 

CALL  ERRORSMSG; 

END  CETSPARAMETERS; 


✓****:fc********:i::.':****:|:*****:*:*:tf****:S*****#*************/ 

/*  GETS REQU I REDS PARAMETERS  - GETS  THE  <DISK  NUMBER> 

AND  < KEY>  PARAMETERS  FOR  THOSE  SYSTEM  CMDS  FOR 
WHICH  THESE  PARAMETERS  ARE  REQUIRED  (NOT 
OPTIONAL)  . GENERATES  ERROR  MSG  IF  PARAMETERS 
ARE  NOT  THERE. 

CALLED  BY : PR0TECT3CMD ; RESTRICT3CMD;  UNPROTECTSCMD 

*/ 

CET8REQU I REDSP ARAMETERS : PROCEDURE; 

IF  CBUFFSNOTSEMPTY  THEN 
CALL  GETSPARAMETERS ; 

ELSE 

CALL  ERRORSMSG; 

END  GETS REQU I REDSP ARAMETERS; 


/##****************************************************/' 
/*****  * SYSTEM  CMD  PROCEDURES  * * * * */ 

/'***********:.':***************:);***************£****»*****/ 


,/**:t::|c*****:fc****:i;S:*******:fc**»:*******:t:***:|:*******:fc*****/ 
/*  ATTACHSCMD  - 

FORM:  ATTACH  < DRIVE  LTR>  <DISK  NR>  /< KEY> 

ALL  THE  PARAMETERS  ARE  OPTIONAL,  HOWEVER 

< KEY>  CAN  NOT  APPEAR  WITHOUT  IT’S  ASSOCIATED 

< DISK  NUMBER).  WHEN  PARAMETERS  ARE  ENTERED 
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THEY  MUST  BE  IN  THE  ORDER  INDICATED. 
CALLED  BY:  MCP  MAIN  CONTROL 


*/ 

ATTACIiaCMD:  PROCEDURE: 

IF  CBUFFSNOTSEMPTY  THEN 
DO: 

CHAR  = READ3CMDSLINE; 

IF  LETTER! CHAR)  THEN  /*  < DRIVE  LETTER>  */ 

DO: 

PARAMETERS!  0) =CHAR-4 1H; /^CONVERT  TO  BINARY*/ 
CALL  DEBLANK: 

IF  CBUFF3N0T3EHPTY  THEN  /*  MORE  PARAMETERS  */ 
CHAR  = READ3CMDSLINE; 

END; 

IF  NUMBER!  CHAR)  THEN  /#  <DISK  NUMBER)  */ 

DO; 

CALL  GET* NUMBER!  1)  ; 

CALL  DEBLANK; 

CALL  GETSKEYi 2) : /*  < KEY>  */ 

CALL  DEBLANK; 

END; 

END; 

IF  CBUFFSNOTSEMPTY  THEN 
CALL  ERRORS MSG; 

ELSE 


CALL  SEND3MTS3CMD! ATTACH, .PARAMETERS) ; 
END  ATTACnSCMD; 


/***:S**S:**^:±***S;***«****»S;W*******:*W******^:****:******/ 

/*  LOG INGCMD  - 

FORM:  LOGIN  <DISK  NUMBER>  /<  KEY') 

THE  PARAMETERS  ARE  OPTIONAL  BUT  < KEY>  CAN  NOT 
APPEAR  WITHOUT  <DISK  NUMBER> . 

CALLED  BY:  MCP  RAIN  CONTROL 

L0GIN8CMD:  PROCEDURE; 

IF  CBUFFSNOTSEMPTY  THEN 

CALL  GETS PARAMETERS ; 

CALL  SENDSMTSSCMD! LOGIN, .PARAMETERS) ; 

END  LOGINSCMD; 


/******aca;:,i:***¥:^:M:*****:K****«****************M:*******Hc*/ 

/*  P R0TECT8 CMD  - 

FORM:  PROTECT  <DISK  NUMBER>  /< KEY> 

THE  PARAMETERS  ARE  REQUIRED. 

CALLED  BY:  MCP  MAIN  CONTROL 

*/ 

PROTECTSCMD:  PROCEDURE: 

CALL  GETSREQU I REDS PARAMETERS ; 

CALL  SENDSMTSSCMD!  PROTECT,  .PARAMETERS): 

END  PROTECTSCMD; 


/**W*V:****************»*******:!:*****:’:****************/ 

/*  QUITSCMD  - FORM:  QUIT 

NO  PARAMETERS. 

CALLED  BY:  MCP  MAIN  CONTROL 

*/ 

QUITSCMD:  PROCEDURE; 

CALL  SENDSMTSSCMD!  QUIT, 0) ; 

END  QUITSCMD; 


/****«**»****:.:***************************************/ 
/*  RESTRICTSCMD  - 

FORM:  RESTRICT  <DISK  NUMBER)  /< KEY> 

THE  PARAMETERS  ARE  REQUIRED. 

CALLED  BY:  MCP  MAIN  CONTROL 

*/ 

RESTRICTSCMD:  PROCEDURE; 
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CALL  GET8REQUIREDSPARAMETERS; 

CALL  SEND8MTS8CMD(  RESTRICT, . PARAMETERS) ; 
END  RESTRICT3CMD; 


/********#***************************:*********:(.•<:*****/' 
/*  UNPROTECTSCMD  - 

FORM:  UNPFiOTECT  <DISK  NUHEER>  /<.  KEY> 

THE  PARAMETERS  ARE  REQUIRED. 

CALLED  BY:  MOP  MAIN  CONTROL 

*/ 

UNPROTECTSCMD:  PROCEDURE; 

CALL  CETSREQU I REDSPARAMETERS ; 

CALL  SENDSMTSSCMDC UNPROTECT, .PARAMETERS) ; 

END  UNPROTECTSCMD; 


/****^***^t***************-4:«*******»:**»W«*»********»#*/ 
/*  S IZESCMD  - 

FORM:  SIZE  < MEMORY  SIZE> 

THE  PARAMETER  19  REQUIRED. 

CALLED  BY:  MCP  MAIN  CONTROL 

*/ 

S IZESCMD:  PROCEDURE; 

IF  CBUTFSNOTSENPTY  THEN 
DO; 

IF  HUMBER! CHAR: =READSCMDOL I RE)  THEN 

DO;  /*  GET  MEMORY  SIZE  PARAMETER  */ 

CALL  GETSNUMBER(O) ; 

CALL  SENDSMTSSCMD(SIZE,  PARAMETERS! 0) ) ; 

END; 

ELSE  '*  PARAMETER  MUST  BE  NUMBER 

CALL  ERRORSMSC;  SPECIFYING  MEMORY  SIZE  */ 

END; 

ELSE  /*  C3UFF  EMPTY  - ERROR  */ 

CALL  ERRORSMSG;  /*  PARAMETER  REQUIRED  */ 

END  S IZESCMD; 


/**%****X-&X**%X*****%*%**********%***'Jf.***X-*.***'X*****'*-*-*./ 
/*  * * MTS  COMMAND  PROCESSOR  (MCP)  TLA  IN  CONTROL  * 

/*  * * CALLED  BY:  MTS  MONITOR  MODULE  * */ 

/XXXX-XXXXXXXXXXCXXXXXXXXX***************-*****?.********#*/' 


DECLARE  STACK  (20)  ADDRESS , OLDSP  ADDRESS; 


OLDSP  = STACKPTR;  /*  SAVE  MTS  STACK  POINTER  */ 

STACKPTR  = . STACK( LENGTH( STACK) ) ; /*  SETUP  MCP  STACKPTR  */ 

CALL  INITIALIZE;  /*  INITIALIZE  DATA  STRUCTURES  *s 

CALL  FILLSCBUFF;  /*  GET  MTS  COMMAND 

CALL  DEBLANK;  /#  SCAN  TO  FIRST  NONBLANK  CHAR  */ 

IF  CBUFFSN0T3 EMPTY  THEN  /*  PROCESS  CMD  BUFFER  */ 

DO; 

CHAR  = READ3CMDSLINE; /*  GET  FIRST  LETTER  OF  CMD  */ 

CALL  SCAN8T08BLANK;  /*  SCAN  TO  NEXT  BLANK,  BECAUSE 

ONLY  THE  FIRST  LETTER  IS  USED 
TO  DETERMINE  THE  CMD 

CALL  DEBLANK; 


IF  CHAR  = ’A’  THEN  /*  ATTACH  */ 

CALL  ATTACH8CMD; 

ELSE 

DO; 

IF  CHAR  = ’L'  THEN  /*  LOGIN  */ 

CALL  L0GIN8CMD; 

ELSE 

DO; 

IF  CHAR  = ’P'  THEN  /'*  PROTECT  •/ 

CALL  PROTECTSCMD; 

ELSE 
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00; 

IF  CHAR  = ’ Q’  THEN  /*  QUIT  */ 

CALL  QUIT3CMD; 

ELSE 

DO; 

IF  CHAR  = ’R’  THEN  /*  RESTRICT  */ 
CALL  RESTR I CTSCMD ; 

ELSE 

DO; 

IF  CHARTS’  THEN  /*  SIZE  */ 
CALL  S1ZE8CMD; 

ELSE 

DO; 

IF  CHAR*  ’ U"  TTIEN/*UNPn.OTECT*/ 
CALL  UNPR0TF.CT9CMD; 

ELSE 

CALL  ERRORSMSG; 

END; 

END; 

END; 

END; 

END; 

END; 

END; 

F1NI: 

STACK? TR  = OLDSP;  /*  RESTORE  ’ITS  MONITOR  STACK? TR  */ 

END  MCP; 


F.OF 
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